> 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

> 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.