<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://trexnegro.github.io/</id><title>SixSixSix</title><subtitle>Long-form vulnerability research and writeups by SixSixSix. Linux kernel exploitation, EDR bypass, Active Directory, web app security, and bug-bounty methodology.</subtitle> <updated>2026-07-07T18:31:26-05:00</updated> <author> <name>SixSixSix</name> <uri>https://trexnegro.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://trexnegro.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://trexnegro.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 SixSixSix </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>OpenConnect Fortinet: server-induced chosen-offset stack write via snprintf-return-value cursor arithmetic</title><link href="https://trexnegro.github.io/posts/openconnect-fortinet-snprintf-cursor-chosen-offset-stack-write/" rel="alternate" type="text/html" title="OpenConnect Fortinet: server-induced chosen-offset stack write via snprintf-return-value cursor arithmetic" /><published>2026-07-07T22:00:00-05:00</published> <updated>2026-07-07T22:00:00-05:00</updated> <id>https://trexnegro.github.io/posts/openconnect-fortinet-snprintf-cursor-chosen-offset-stack-write/</id> <content type="text/html" src="https://trexnegro.github.io/posts/openconnect-fortinet-snprintf-cursor-chosen-offset-stack-write/" /> <author> <name>SixSixSix</name> </author> <category term="Research" /> <category term="Linux" /> <summary>A ten-line C block in OpenConnect's Fortinet handler builds a version-info string with the classic snprintf-cursor idiom: advance a pointer by snprintf's return value across successive calls into a fixed stack buffer. Because snprintf returns the length it *would have* written — not the length it did — a single oversized field advances the cursor past the buffer end. The subsequent size argument computed as `e - p` is a negative ptrdiff_t that implicitly converts to a near-SIZE_MAX size_t. The next call happily writes a short, format-string-controlled payload at a caller-chosen offset — including the saved-RIP slot of the parent stack frame. Full walkthrough of the C language semantics that make the primitive, the stack-frame math that lands the write on saved RIP, the mitigation matrix (FORTIFY catches, SSP does not), and the pattern to grep for in any C codebase that builds strings incrementally.</summary> </entry> <entry><title>Case-variant path aliases in Rust denial gates: anatomy of a canonicalize-fallback bypass</title><link href="https://trexnegro.github.io/posts/mxc-sdk-hyperlight-canonicalize-case-alias-bypass/" rel="alternate" type="text/html" title="Case-variant path aliases in Rust denial gates: anatomy of a canonicalize-fallback bypass" /><published>2026-07-07T20:00:00-05:00</published> <updated>2026-07-07T20:00:00-05:00</updated> <id>https://trexnegro.github.io/posts/mxc-sdk-hyperlight-canonicalize-case-alias-bypass/</id> <content type="text/html" src="https://trexnegro.github.io/posts/mxc-sdk-hyperlight-canonicalize-case-alias-bypass/" /> <author> <name>SixSixSix</name> </author> <category term="Research" /> <category term="Rust" /> <summary>A four-line Rust function that gates a real-world sandbox against overlap between allow and deny lists reduces to raw byte comparison on the common case. Combined with NTFS's default case-insensitivity and Rust's PathBuf equality semantics, the gate silently admits any policy whose colliding entries differ only in case, so long as one side of the collision does not yet exist on disk. Deep walkthrough of the primitive, its NTFS/Rust interaction, an end-to-end reproducer, a minimal fix, and the static-analysis pattern that identifies the same shape across any Rust codebase.</summary> </entry> <entry><title>Android IncFS verity-signature race — and what Google ASR "Won't Fix (Infeasible)" actually means</title><link href="https://trexnegro.github.io/posts/android-incfs-verity-signature-race-google-asr-infeasible/" rel="alternate" type="text/html" title="Android IncFS verity-signature race — and what Google ASR &amp;quot;Won&amp;apos;t Fix (Infeasible)&amp;quot; actually means" /><published>2026-06-15T22:30:00-05:00</published> <updated>2026-06-16T13:46:31-05:00</updated> <id>https://trexnegro.github.io/posts/android-incfs-verity-signature-race-google-asr-infeasible/</id> <content type="text/html" src="https://trexnegro.github.io/posts/android-incfs-verity-signature-race-google-asr-infeasible/" /> <author> <name>SixSixSix</name> </author> <category term="Research" /> <category term="Android Kernel" /> <summary>fs/incfs/verity.c::incfs_read_signature() declares its working pointer to the verity-signature heap buffer as `static`. The qualifier puts the pointer in a single BSS slot shared across every invocation from every thread or process on the system. Two racing ioctl calls produce a KASAN double-free in kmalloc-256, a cross-process information leak, a KASLR-relevant kernel pointer disclosure, and — on a kernel with CONFIG_SLAB_FREELIST_HARDENED + RANDOM + KASLR all on — SLUB freelist corruption with attacker-controlled bytes. Reported to Google ASR, closed Won't Fix (Infeasible) five weeks later. This post walks the bug from first principles — what IncFS is, what fs-verity does, why the `static` keyword turns a function-local pointer into a global weapon, what each runtime primitive actually buys an attacker, how Google's vulnerability reward program triages, and what the "Infeasible" verdict really communicates.</summary> </entry> <entry><title>An Android Bluetooth ISO out-of-bounds write that lands RIP on `commit_creds`, marked Infeasible by Google ASR</title><link href="https://trexnegro.github.io/posts/android-iso-per-adv-oob-rip-control-google-asr-infeasible/" rel="alternate" type="text/html" title="An Android Bluetooth ISO out-of-bounds write that lands RIP on `commit_creds`, marked Infeasible by Google ASR" /><published>2026-06-11T16:00:00-05:00</published> <updated>2026-06-11T16:00:00-05:00</updated> <id>https://trexnegro.github.io/posts/android-iso-per-adv-oob-rip-control-google-asr-infeasible/</id> <content type="text/html" src="https://trexnegro.github.io/posts/android-iso-per-adv-oob-rip-control-google-asr-infeasible/" /> <author> <name>SixSixSix</name> </author> <category term="Research" /> <category term="Kernel" /> <category term="Android" /> <category term="Vulnerability Disclosure" /> <summary>A pre-auth, adjacent-network OOB write in `iso_connect_ind()` in `net/bluetooth/iso.c` on Android Common Kernel 15 (6.6). Eight reboots of attacker-byte RIP control. Twelve reboots reaching `commit_creds+0x8f8`. Two sibling bugs in the same handler. Reported to the Android &amp; Devices VRP on 2026-05-11, updated 2026-05-28 with the RIP-control + sibling-bug package. Closed by Google as **Infeasible** on 2026-06-11. This is the full technical writeup and the experience around the verdict.</summary> </entry> <entry><title>Two Lenovo Power Manager kernel drivers, one Everyone:RW DACL — a class-pattern in TPPWR64V and ibmpmdrv</title><link href="https://trexnegro.github.io/posts/lenovo-pm-family-dacl-class-pattern/" rel="alternate" type="text/html" title="Two Lenovo Power Manager kernel drivers, one Everyone:RW DACL — a class-pattern in TPPWR64V and ibmpmdrv" /><published>2026-06-05T18:00:00-05:00</published> <updated>2026-06-05T18:00:00-05:00</updated> <id>https://trexnegro.github.io/posts/lenovo-pm-family-dacl-class-pattern/</id> <content type="text/html" src="https://trexnegro.github.io/posts/lenovo-pm-family-dacl-class-pattern/" /> <author> <name>SixSixSix</name> </author> <category term="Research" /> <category term="BYOVD" /> <category term="Vulnerability Disclosure" /> <summary>Two Lenovo Power Manager kernel drivers ship with their device DACL granting Everyone (S-1-1-0) read+write. Any local user — including restricted-token sandboxes — can open the device and reach the IOCTL dispatcher. On `TPPWR64V.SYS` the dispatcher is a gateway to SMAPI Embedded Controller port I/O; on `ibmpmdrv.sys` it returns 18+ kernel-side state values. The identical SDDL on two unrelated devices points at a shared driver-creation template that's worth a class-level audit. Disclosed to Lenovo PSIRT 2026-06-05; this post is the full technical writeup.</summary> </entry> </feed>
