This looks like a csectype-undefined and/or csectype-wildptr. The central problem is accessing front() and then then pop() on an empty std::queue, which would have undefined behavior and could place an unknown/unpredictable value (it would vary by C++ stdlib implementation) in a shmem handle container. Having a random value in a shmem handle doesn't automatically mean that you can then associate a useful value with that shmem handle, since that value comes from popping the empty std::queue, and the more likely outcome is simply some form of crashing. If you could successfully redirect a valid shmem into the handle via this bug, this seemingly wouldn't necessarily advance a hacker's goals beyond just explicitly overwriting the contents of the existing shmem from the content process (which does not require any messing with the handle or exploit otherwise).
Bug 1986185 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This looks like a csectype-undefined and/or csectype-wildptr. The central problem is accessing front() and then then pop() on an empty std::queue, which would have undefined behavior and could place an unknown/unpredictable value (it would vary by C++ stdlib implementation) in a shmem handle container. Having a random value in a shmem handle doesn't automatically mean that you can then associate a useful value with that shmem handle, since that value comes from popping the empty std::queue, and the more likely outcome is simply some form of crashing. If you could successfully redirect a valid shmem into the handle via this bug, this doesn't necessarily advance a hacker's goals beyond just explicitly overwriting the contents of the existing shmem from the content process (which does not require any messing with the handle or exploit otherwise). You would have to redirect to some other shmem created by another process for it to be worrisome, but the mechanism for how you would do such a thing is unclear, as the memory returned from an empty front() or pop(), while undefined, is not arbitrarily specifiable?
This looks like a csectype-undefined and/or csectype-wildptr. The central problem is accessing front() and then then pop() on an empty std::queue, which would have undefined behavior and could place an unknown/unpredictable value (it would vary by C++ stdlib implementation) in a shmem handle container. Having a random value in a shmem handle doesn't automatically mean that you can then associate a useful value with that shmem handle, since that value comes from popping the empty std::queue, and the more likely outcome is simply some form of crashing. If you could successfully redirect a valid shmem into the handle via this bug, this doesn't necessarily advance a hacker's goals beyond just explicitly overwriting the contents of the existing shmem from the content process (which does not require any messing with the handle or exploit otherwise). You would have to redirect to some other shmem created by another process for it to be worrisome, and it would still need to be formatted as a canvas command stream to effectively do anything with it, but the mechanism for how you would do such a thing is unclear, as the memory returned from an empty front() or pop(), while undefined, is not arbitrarily specifiable?