| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-36962: net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs |
| |
| Currently the driver uses local_bh_disable()/local_bh_enable() in its |
| IRQ handler to avoid triggering net_rx_action() softirq on exit from |
| netif_rx(). The net_rx_action() could trigger this driver .start_xmit |
| callback, which is protected by the same lock as the IRQ handler, so |
| calling the .start_xmit from netif_rx() from the IRQ handler critical |
| section protected by the lock could lead to an attempt to claim the |
| already claimed lock, and a hang. |
| |
| The local_bh_disable()/local_bh_enable() approach works only in case |
| the IRQ handler is protected by a spinlock, but does not work if the |
| IRQ handler is protected by mutex, i.e. this works for KS8851 with |
| Parallel bus interface, but not for KS8851 with SPI bus interface. |
| |
| Remove the BH manipulation and instead of calling netif_rx() inside |
| the IRQ handler code protected by the lock, queue all the received |
| SKBs in the IRQ handler into a queue first, and once the IRQ handler |
| exits the critical section protected by the lock, dequeue all the |
| queued SKBs and push them all into netif_rx(). At this point, it is |
| safe to trigger the net_rx_action() softirq, since the netif_rx() |
| call is outside of the lock that protects the IRQ handler. |
| |
| The Linux kernel CVE team has assigned CVE-2024-36962 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.1.87 with commit 492337a4fbd1421b42df684ee9b34be2a2722540 and fixed in 6.1.91 with commit 8a3ff43dcbab7c96f9e8cf2bd1049ab8d6e59545 |
| Issue introduced in 6.6.28 with commit cba376eb036c2c20077b41d47b317d8218fe754f and fixed in 6.6.31 with commit ae87f661f3c1a3134a7ed86ab69bf9f12af88993 |
| Issue introduced in 6.8.7 with commit 49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b and fixed in 6.8.10 with commit 7e2901a2a9195da76111f351584bf77552a038f0 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2024-36962 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/net/ethernet/micrel/ks8851_common.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/8a3ff43dcbab7c96f9e8cf2bd1049ab8d6e59545 |
| https://git.kernel.org/stable/c/ae87f661f3c1a3134a7ed86ab69bf9f12af88993 |
| https://git.kernel.org/stable/c/7e2901a2a9195da76111f351584bf77552a038f0 |
| https://git.kernel.org/stable/c/e0863634bf9f7cf36291ebb5bfa2d16632f79c49 |
