CVE 2025 31200

I remember when I was doing iOS/macOS security research back in 2015 and I though to myself "I bet core audio has bugs.." but never really looked into them because my thinking was they wouldn't have been too too useful unless you can get someone to open an audio file... But great work.

Is there a typo in the code block for the `Process` function near the end of the post? Lines 13-15 have the following loop:

        while (remapVec[remapStartIndex] >= index) { // Follow the 'cycle'
            index = remapVec[remapStartIndex];
        }

I'm not sure what that loop is supposed to be doing, but as its written it looks like it would either be skipped entirely or never terminate; after single iteration, the the two values would be equal and never change again.

When I click this link my work's firewall blocks me, asking if I want to proceed to:

    http://gambling.com ?url=https://blog.noahhw.dev/posts/cve-2025-31200/

Which is weird cause that redirect url is to exactly what's linked in the post. It only happens on this link.

I’d be really frustrated if my device was compromised by an esoteric audio format that I had no intention of ever listening to.

If these parsers can’t run inside an isolated process, perhaps they shouldn’t be enabled at all?

> attack against specific targeted individuals on iOS

I'm sure Pegasus will come up with another exploit to replace this one.

> Essentially, if you have a vector, say [A,B,C] that you actually want to be [B,A,C], then you might do that with a ‘permutation map’: another vector that says where each element should go. In this case that would be [1,0,2], which means that the element at index 1 should go to index 0, and the element at index 0 should go to index 1 and the element at index 2 should stay where it is. The simplest working way to do this is to just allocate another vector, and essentially use the permutation map as a kind of dictionary (index→element) for populating that third vector. However, if you would rather be clever and don’t feel like allocating a whole other vector, then you can use the algorithm above.

This isn't being clever, it's actually incorrect to allocate a whole other vector. Realtime code requires O(1) memory complexity for correctness. Although the smart thing would be to preallocate a buffer for the pointers, but in general that may not be possible (I'm not an expert in CoreAudio but if the channels are interleaved and the next chunk of code expects to process in place you really do have to it this way).

It sounds like the CVE is super simple, reduced to:

- CoreAudio determines the number of channels before playback to create a resource, standard practice in audio processing

- It then trusts the number of channels of an incoming stream when using that resource

- A maliciously crafted audio file can bypass checks for this and trigger a buffer overflow

Never trust your inputs, folks.

The reason this comes up with HOA to me is not surprising: almost no one uses HOA, and a variety of other optimizations like assuming the "H" in HOA only refers to up to 128 channels (since afaik, no one even tries past that point).

> Imagine if the primitive is that you can write n 8 byte sequences out of bounds, but they must be valid 32 bit floats in the range x-y

I imagine the only thing you need to guarantee is you don't use subnormals, since audio code usually enables FTZ mode on both ARM and x86.