CVE-2024-53119: virtio/vsock: Fix accept_queue memory leak
In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Fix acceptqueue memory leak
As the final stages of socket destruction may be delayed, it is possible that virtiotransportrecvlisten() will be called after the acceptqueue has been flushed, but before the SOCKDONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.
vsockrelease vsockrelease lock virtiotransportrelease virtiotransportclose scheduledelayedwork(closework) skshutdown = SHUTDOWNMASK (!) flush acceptqueue release virtiotransportrecvpkt vsockfindboundsocket lock if flag(SOCKDONE) return virtiotransportrecvlisten child = vsockcreateconnected (!) vsockenqueueaccept(child) release closework lock virtiotransportdoclose setflag(SOCKDONE) virtiotransportremovesock vsockremovesock vsockremovebound release
Introduce a skshutdown check to disallow vsockenqueueaccept() during socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmemcacheallocnoprof+0x2c1/0x360 [<ffffffff81d27aa0>] skprotalloc+0x30/0x120 [<ffffffff81d2b54c>] skalloc+0x2c/0x4b0 [<ffffffff81fe049a>] vsockcreate.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtiotransportrecvpkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsockloopbackwork+0xfd/0x140 [<ffffffff810fc6ac>] processonework+0x20c/0x570 [<ffffffff810fce3f>] workerthread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] retfromfork+0x2d/0x50 [<ffffffff8100785a>] retfromforkasm+0x1a/0x30
Other sources
In the Linux kernel, the following vulnerability has been resolved:
virtio/vsock: Fix acceptqueue memory leak
As the final stages of socket destruction may be delayed, it is possible that virtiotransportrecvlisten() will be called after the acceptqueue has been flushed, but before the SOCKDONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.
vsockrelease vsockrelease lock virtiotransportrelease virtiotransportclose scheduledelayedwork(closework) skshutdown = SHUTDOWNMASK (!) flush acceptqueue release virtiotransportrecvpkt vsockfindboundsocket lock if flag(SOCKDONE) return virtiotransportrecvlisten child = vsockcreateconnected (!) vsockenqueueaccept(child) release closework lock virtiotransportdoclose setflag(SOCKDONE) virtiotransportremovesock vsockremovesock vsockremovebound release
Introduce a skshutdown check to disallow vsockenqueueaccept() during socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [ffffffff81418ff1] kmemcacheallocnoprof+0x2c1/0x360 [ffffffff81d27aa0] skprotalloc+0x30/0x120 [ffffffff81d2b54c] skalloc+0x2c/0x4b0 [ffffffff81fe049a] vsockcreate.constprop.0+0x2a/0x310 [ffffffff81fe6d6c] virtiotransportrecvpkt+0x4dc/0x9a0 [ffffffff81fe745d] vsockloopbackwork+0xfd/0x140 [ffffffff810fc6ac] processonework+0x20c/0x570 [ffffffff810fce3f] workerthread+0x1bf/0x3a0 [ffffffff811070dd] kthread+0xdd/0x110 [ffffffff81044fdd] retfromfork+0x2d/0x50 [ffffffff8100785a] retfromforkasm+0x1a/0x30
— IBM
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.22-1Fixed in 6.12.25-1 - Upgrade
Upgrade
debian/linux-6.1to a version that resolves this vulnerability.Fixed in 6.1.129-1~deb11u1 - Configuration
Apply the virtio/vsock fix by introducing a sk_shutdown check so that vsock_enqueue_accept() is disallowed during socket destruction when accept_queue may be flushed but SOCK_DONE is not yet set.
Linux kernel virtio/vsock sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction = enabled (introduce sk_shutdown check in accept_queue path)
Event History
Frequently Asked Questions
What is the severity of CVE-2024-53119?
CVE-2024-53119 is classified with moderate severity due to its potential for memory leak in the Linux kernel.
How do I fix CVE-2024-53119?
To fix CVE-2024-53119, update your Linux kernel to the latest version that addresses the memory leak issue.
Which versions of the Linux kernel are affected by CVE-2024-53119?
CVE-2024-53119 affects Linux kernel versions from 5.10 to 6.1.119 and various versions in the 6.12 release candidate series.
What are the potential consequences of CVE-2024-53119?
The consequences of CVE-2024-53119 may include increased memory usage which could lead to degraded system performance or service interruptions.
Is there a temporary workaround for CVE-2024-53119 before applying a patch?
There is no documented temporary workaround for CVE-2024-53119; applying the appropriate kernel update is recommended.