Peter Robinson

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A vulnerability has been resolved in the Linux kernel related to the wifi driver rtw88. When removing kernel modules, the driver uses skb queue purge() to purge TX skb but does not report tx status, causing a "Have pending ack frames!" warning. To correct this, ieee80211 purge tx queue() is used. Since ieee80211 purge tx queue() does not take locks, to prevent racing between TX work and purge TX queue, TX work is flushed and destroyed in advance. **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** Linux kernel versions prior to 5.17.0-rc7 **Description** A vulnerability in the Linux kernel has been identified, specifically in the bcmgenet module. The issue arises due to the compiler's optimization of register read and write operations, which can cause problems with the ordering of packet data and in-memory rings/queues. This can lead to errors such as transmit queue timeouts. The vulnerability is related to the use of relaxed variants of register read and write operations, which can be reordered by the compiler, causing issues with device memory mapping and synchronization. **Recommendations** To resolve the issue, use stronger register read and write operations, such as readl and writel, instead of the relaxed variants. This can help ensure proper ordering of operations and prevent errors. As a temporary workaround, consider adding dma mb() operations around the affected code to suppress timeouts, but note that this may not fully resolve the issue. A better approach is to use the safer readl and writel operations everywhere.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 5.11.0+ **Description** The vulnerability is related to the `kmap local()` function in the Linux kernel, which doubles the number of per-CPU fixmap slots allocated for `kmap local()` to use half of them as guard regions. This causes the fixmap region to grow downwards beyond the start of its reserved window if the supported number of CPUs is large, and collide with the newly added virtual DT mapping right below it. One manifestation of this is EFI boot on a kernel built with `NR CPUS=32` and `CONFIG DEBUG KMAP LOCAL=y`, which may pass the FDT in highmem, resulting in block entries below the fixmap region that the fixmap code misidentifies as fixmap table entries, and subsequently tries to dereference using a phys-to-virt translation that is only valid for lowmem. **Recommendations** To resolve the issue, limit `CONFIG NR CPUS` to 16 when `CONFIG DEBUG KMAP LOCAL=y`. Also, fix the `BUILD BUG ON()` check that was supposed to catch this, by checking whether the region grows below the start address rather than above the end address. As a temporary workaround, consider disabling the `kmap local()` function until a patch is available.

**Name of the Vulnerable Software and Affected Versions** PackageKit version 0.6.17 **Description** The issue allows the installation of unsigned RPM packages as though they were signed, potentially enabling the installation of non-trusted packages and the execution of arbitrary code. **Recommendations** For PackageKit version 0.6.17, update to a version that includes a fix for this issue to prevent the installation of unsigned RPM packages. At the moment, there is no information about a newer version that contains a fix for this vulnerability.