| 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-53140: netlink: terminate outstanding dump on socket close |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| netlink: terminate outstanding dump on socket close |
| |
| Netlink supports iterative dumping of data. It provides the families |
| the following ops: |
| - start - (optional) kicks off the dumping process |
| - dump - actual dump helper, keeps getting called until it returns 0 |
| - done - (optional) pairs with .start, can be used for cleanup |
| The whole process is asynchronous and the repeated calls to .dump |
| don't actually happen in a tight loop, but rather are triggered |
| in response to recvmsg() on the socket. |
| |
| This gives the user full control over the dump, but also means that |
| the user can close the socket without getting to the end of the dump. |
| To make sure .start is always paired with .done we check if there |
| is an ongoing dump before freeing the socket, and if so call .done. |
| |
| The complication is that sockets can get freed from BH and .done |
| is allowed to sleep. So we use a workqueue to defer the call, when |
| needed. |
| |
| Unfortunately this does not work correctly. What we defer is not |
| the cleanup but rather releasing a reference on the socket. |
| We have no guarantee that we own the last reference, if someone |
| else holds the socket they may release it in BH and we're back |
| to square one. |
| |
| The whole dance, however, appears to be unnecessary. Only the user |
| can interact with dumps, so we can clean up when socket is closed. |
| And close always happens in process context. Some async code may |
| still access the socket after close, queue notification skbs to it etc. |
| but no dumps can start, end or otherwise make progress. |
| |
| Delete the workqueue and flush the dump state directly from the release |
| handler. Note that further cleanup is possible in -next, for instance |
| we now always call .done before releasing the main module reference, |
| so dump doesn't have to take a reference of its own. |
| |
| The Linux kernel CVE team has assigned CVE-2024-53140 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 4.19.325 with commit 114a61d8d94ae3a43b82446cf737fd757021b834 |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 5.4.287 with commit 598c956b62699c3753929602560d8df322e60559 |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 5.10.231 with commit 6e3f2c512d2b7dbd247485b1dd9e43e4210a18f4 |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 5.15.174 with commit d2fab3d66cc16cfb9e3ea1772abe6b79b71fa603 |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 6.1.119 with commit 4e87a52133284afbd40fb522dbf96e258af52a98 |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 6.6.63 with commit bbc769d2fa1b8b368c5fbe013b5b096afa3c05ca |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 6.11.10 with commit 176c41b3ca9281a9736b67c6121b03dbf0c8c08f |
| Issue introduced in 4.9 with commit ed5d7788a934a4b6d6d025e948ed4da496b4f12e and fixed in 6.12 with commit 1904fb9ebf911441f90a68e96b22aa73e4410505 |
| Issue introduced in 4.4.38 with commit baaf0c65bc8ea9c7a404b09bc8cc3b8a1e4f18df |
| Issue introduced in 4.8.14 with commit 25d9b4bb64ea964769087fc5ae09aee9c838d759 |
| |
| 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-53140 |
| 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: |
| net/netlink/af_netlink.c |
| net/netlink/af_netlink.h |
| |
| |
| 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/114a61d8d94ae3a43b82446cf737fd757021b834 |
| https://git.kernel.org/stable/c/598c956b62699c3753929602560d8df322e60559 |
| https://git.kernel.org/stable/c/6e3f2c512d2b7dbd247485b1dd9e43e4210a18f4 |
| https://git.kernel.org/stable/c/d2fab3d66cc16cfb9e3ea1772abe6b79b71fa603 |
| https://git.kernel.org/stable/c/4e87a52133284afbd40fb522dbf96e258af52a98 |
| https://git.kernel.org/stable/c/bbc769d2fa1b8b368c5fbe013b5b096afa3c05ca |
| https://git.kernel.org/stable/c/176c41b3ca9281a9736b67c6121b03dbf0c8c08f |
| https://git.kernel.org/stable/c/1904fb9ebf911441f90a68e96b22aa73e4410505 |
