Maik Muench

**Name of the Vulnerable Software and Affected Versions** The product name cannot be determined (affected versions not specified) **Description** The `GETALL` and `SETALL` commands in the `semctl()` function contain a flaw in how they handle semaphore sets. The process records the number of semaphores, releases the protecting lock, allocates a buffer, and then reacquires the lock. While a sequence-number check is used to ensure the set was not replaced, this number wraps after 0x8000 create and destroy cycles. A local unprivileged user can rapidly destroy and recreate semaphore sets at the same index to cause this wrap, bypassing validation and triggering out-of-bounds reads and writes on kernel heap memory, which may lead to privilege escalation. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** The product name cannot be determined (affected versions not specified) **Description** A race condition exists in the ELF core dump code. The system counts dumpable VM map entries and allocates a buffer for program headers, then iterates over the map again to populate them. A process sharing the address space via the `rfork(2)` function can mutate the map between these two passes, resulting in an out-of-bounds write on the kernel heap. This allows an unprivileged local user sharing an address space with a process that dumps core to potentially achieve privilege escalation. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** FreeBSD (affected versions not specified) **Description** A use-after-free issue exists in the `tcp rack.ko` kernel module. The RACK `setsockopt(2)` handler releases the connection lock to copy option data from userspace and subsequently reacquires it. While the handler verifies that the TCP stack was not switched, it fails to reload the pointer to the stack's per-connection control block. If userspace triggers stack switches twice during this interval, the verification succeeds, but the saved pointer references memory that has already been freed. An unprivileged local user could exploit this to escalate privileges. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.