/self/proc/mem

Posted Jan 17, 2026 5:15 UTC (Sat) by cypherpunks2 (guest, #152408)
Parent article: A 0-click exploit chain for the Pixel 9 (Project Zero)

> This syncframe uses DYNAMIC WRITE FAST to write ‘wb’ and “/self/proc/mem” to the address above, so they are available as parameters for a future fopen call, then moves the skip pointer to dynamic_base + 0xD000, so they aren’t immediately corrupted.

> Likewise, the accessibility of /self/proc/mem was a big shortcut to exploitation. Since it is only used during debugging, I wonder if it is possible to implement some sort of mitigation that makes it inaccessible when a device is not being debugged.

I assume they mean /proc/self/mem? I wonder how they made that kind of mistake twice.

to post comments

/self/proc/mem

Posted Jan 20, 2026 9:25 UTC (Tue) by evomassiny (subscriber, #161550) [Link] (1 responses)

Same for the pseudo-code,
i believe:
```
if ( total_size % 8 )
total_size += (8 - total_size) % total_size;
```

should be:
```
if (total_size % 8)
total_size += 8 - (total_size % 8);
```
otherwise i don't understand what would be the intention

/self/proc/mem

Posted Jan 20, 2026 11:53 UTC (Tue) by excors (subscriber, #95769) [Link]

I can't find the ddp_udc_int_evo_malloc symbol in Pixel 9's libcodec2_soft_ddpdec.so (maybe it was inlined or something); but the original bug report says the vulnerable code is present on MacOS, and a GitHub search shows the symbol exists on iOS (which is probably similar to MacOS), so I guess they decompiled it from MacOS rather than Android.

The iOS decompilation is effectively:

total_size = (alloc_size + extra + 7) & ~7;
if (does_add_overflow(alloc_size, extra) || heap->remaining < total_size) { return 0; }

which makes more sense - it's simply rounding up to 8 bytes, and the bug is that it's only testing for overflow in the non-rounded-up addition. Perhaps the post author tried to paraphrase the decompiled code to avoid the slightly obscure bit-twiddling, or used a different decompiler that produced uglier code they needed to clean up, but they made a mistake. Their rest of their explanation of the overflow sounds fine.

(They say the overflow is present on iOS but not exploitable because the library is built with -fbounds-safety.)