CVE-2021-47024

vsock/virtio: free queued packets when closing socket

5.5 MediumFix available

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work.

To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Attack profile

How easy it is to exploit

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: None
Integrity: None
Availability: High

Exploit likelihood

0.25%Up 0.2 points since Feb 29, 2024

What each source reports

NVD Score used5.5

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Record: CVE-2021-47024
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-401
Updated: 2026-11-02

CVE ListNo score

vsock/virtio: free queued packets when closing socket

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Record: CVE-2021-47024
Updated: 2026-11-02

EUVDEUVD-2021-33672No score

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Record: EUVD-2021-33672
Updated: 2026-11-02

GitHub AdvisoriesGHSA-wwcj-mm94-5r395.5

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued...

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Record: GHSA-wwcj-mm94-5r39
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-401
Updated: 2026-11-02

OSV5.5

In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Record: CVE-2021-47024
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVDEBIAN-CVE-2021-470245.5

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

Record: DEBIAN-CVE-2021-47024
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

Show 6 moreShow less

OSVOESA-2024-13457.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

i2c: xiic: fix reference leak when pm_runtime_get_sync fails

The PM reference count is not expected to be incremented on return in xiic_xfer and xiic_i2c_remove.

However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.

Replace it with pm_runtime_resume_and_get to keep usage counter balanced.(CVE-2020-36778)

In the Linux kernel, the following vulnerability has been resolved:

i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails

The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable.

However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.

Replace it with pm_runtime_resume_and_get to keep usage counter balanced.(CVE-2020-36782)

In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: fix info leak in hid_submit_ctrl

In hid_submit_ctrl(), the way of calculating the report length doesn't take into account that report->size can be zero. When running the syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to calculate transfer_buffer_length as 16384. When this urb is passed to the usb core layer, KMSAN reports an info leak of 16384 bytes.

To fix this, first modify hid_report_len() to account for the zero report size case by using DIV_ROUND_UP for the division. Then, call it from hid_submit_ctrl().(CVE-2021-46906)

In the Linux kernel, the following vulnerability has been resolved:

ARM: footbridge: fix PCI interrupt mapping

Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()"), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised.(CVE-2021-46909)

In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: core: Do core softreset when switch mode

According to the programming guide, to switch mode for DRD controller, the driver needs to do the following.

To switch from device to host:

Reset controller with GCTL.CoreSoftReset
Set GCTL.PrtCapDir(host mode)
Reset the host with USBCMD.HCRESET
Then follow up with the initializing host registers sequence

To switch from host to device:

Reset controller with GCTL.CoreSoftReset
Set GCTL.PrtCapDir(device mode)
Reset the device with DCTL.CSftRst
Then follow up with the initializing registers sequence

Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2].

So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device.

[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/(CVE-2021-46941)

In the Linux kernel, the following vulnerability has been resolved:

openvswitch: fix stack OOB read while fragmenting IPv4 packets

running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets:

BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367

CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+…

Record: OESA-2024-1345
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2024-13467.8