CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53192 – clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access
https://notcve.org/view.php?id=CVE-2024-53192
In the Linux kernel, the following vulnerability has been resolved: clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access Flexible-array member `hws` in `struct clk_hw_onecell_data` is annotated with the `counted_by()` attribute. This means that when memory is allocated for this array, the _counter_, which in this case is member `num` in the flexible structure, should be set to the maximum number of elements the flexible array can contain, or fewer. In this case, the total number of elements for the flexible array is determined by variable `clks_num` when allocating heap space via `devm_kzalloc()`, as shown below: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); So, `clp->clk_data.num` should be set to `clks_num` or less, and not exceed `clks_num`, as is currently the case. Otherwise, if data is written into `clp->clk_data.hws[clks_num]`, the instrumentation provided by the compiler won't detect the overflow, leading to a memory corruption bug at runtime. Fix this issue by setting `clp->clk_data.num` to `clks_num`. • https://git.kernel.org/stable/c/9796ec0bd04bb0e70487127d44949ca0554df5d3 https://git.kernel.org/stable/c/b96fc194984d0c82de1ca2b4166b35b1298b216c https://git.kernel.org/stable/c/1bf8877150128c3abd9d233886a05f6966fbf0c7 https://git.kernel.org/stable/c/02fb4f0084331ef72c28d0c70fcb15d1bea369ec •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-53191 – wifi: ath12k: fix warning when unbinding
https://notcve.org/view.php?id=CVE-2024-53191
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath12k_pci), and we get: WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80 Call Trace: free_large_kmalloc ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free. • https://git.kernel.org/stable/c/d889913205cf7ebda905b1e62c5867ed4e39f6c2 https://git.kernel.org/stable/c/223b546c6222d42147eff034433002ca5e2e7e09 https://git.kernel.org/stable/c/90556b96338aa6037cd26dac857327fda7c19732 https://git.kernel.org/stable/c/94c9100b600f05a36b33f9ed76dbd6fb0eb25386 https://git.kernel.org/stable/c/ca68ce0d9f4bcd032fd1334441175ae399642a06 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-53190 – wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
https://notcve.org/view.php?id=CVE-2024-53190
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? • https://git.kernel.org/stable/c/c386fb76f01794f1023d01a6ec5f5c93d00acd3b https://git.kernel.org/stable/c/8f3551f67991652c83469c7dd51d7b9b187b265f https://git.kernel.org/stable/c/eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c https://git.kernel.org/stable/c/ac064c656f105b9122bc43991a170f95f72b7a43 https://git.kernel.org/stable/c/5c1b544563005a00591a3aa86ecff62ed4d11be3 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-53189 – wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan
https://notcve.org/view.php?id=CVE-2024-53189
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan The channels array in the cfg80211_scan_request has a __counted_by attribute attached to it, which points to the n_channels variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of allocated memory as the initial value for n_channels. It is updated with the actual number of added elements after the array is filled. • https://git.kernel.org/stable/c/aa4ec06c455d0200eea0a4361cc58eb5b8bf68c4 https://git.kernel.org/stable/c/d4ef643ea78c59c22546046c25dc6e7206267672 https://git.kernel.org/stable/c/1a7b62ddf2c7642878c24f0e556041bb58c37527 https://git.kernel.org/stable/c/9c46a3a5b394d6d123866aa44436fc2cd342eb0d •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-53188 – wifi: ath12k: fix crash when unbinding
https://notcve.org/view.php?id=CVE-2024-53188
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix crash when unbinding If there is an error during some initialization related to firmware, the function ath12k_dp_cc_cleanup is called to release resources. However this is released again when the device is unbinded (ath12k_pci), and we get: BUG: kernel NULL pointer dereference, address: 0000000000000020 at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k] Call Trace: ath12k_dp_cc_cleanup ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set to NULL the released structure in ath12k_dp_cc_cleanup at the end. • https://git.kernel.org/stable/c/d889913205cf7ebda905b1e62c5867ed4e39f6c2 https://git.kernel.org/stable/c/81da9c0854545c3188ca2a09afe7cb65f9c012b5 https://git.kernel.org/stable/c/2eec88c0fa63f8ad35704a8c9df0b5bd8694fcda https://git.kernel.org/stable/c/488d2959c28621e52b3cce118a813a4bc18bb3d1 https://git.kernel.org/stable/c/1304446f67863385dc4c914b6e0194f6664ee764 •