CVE-2024-56674: virtio_net: correct netdev_tx_reset_queue() invocation point

Published Dec 27, 2024
·
Updated

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

virtionet: correct netdevtxresetqueue() invocation point

When virtnetclose is followed by virtnetopen, some TX completions can possibly remain unconsumed, until they are finally processed during the first NAPI poll after the netdevtxresetqueue(), resulting in a crash [1]. Commit b96ed2c97c79 ("virtionet: move netdevtxresetqueue() call before RX napi enable") was not sufficient to eliminate all BQL crash cases for virtio-net.

This issue can be reproduced with the latest net-next master by running: while :; do ip l set DEV down; ip l set DEV up; done under heavy network TX load from inside the machine.

netdevtxresetqueue() can actually be dropped from virtnetopen path; the device is not stopped in any case. For BQL core part, it's just like traffic nearly ceases to exist for some period. For stall detector added to BQL, even if virtnetclose could somehow lead to some TX completions delayed for long, followed by virtnetopen, we can just take it as stall as mentioned in commit 6025b9135f7a ("net: dqs: add NIC stall detector based on BQL"). Note also that users can still reset stallmax via sysfs.

So, drop netdevtxresetqueue() from virtnetenablequeuepair(). This eliminates the BQL crashes. As a result, netdevtxresetqueue() is now explicitly required in freeze/restore path. This patch adds it to immediately after freeunusedbufs(), following the rule of thumb: netdevtxresetqueue() should follow any SKB freeing not followed by netdevtxcompletedqueue(). This seems the most consistent and streamlined approach, and now netdevtxresetqueue() runs whenever freeunusedbufs() is done.

[1]: ------------[ cut here ]------------ kernel BUG at lib/dynamicqueuelimits.c:99! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G N 6.12.0net-nextmain+ #2 Tainted: [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), \ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dqlcompleted+0x26b/0x290 Code: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d 4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff <0f> 0b 01 d2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff RSP: 0018:ffffc900002b0d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009 RDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000 RBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001 R13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40 FS: 00007f41ded69500(0000) GS:ffff888667dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <IRQ> ? die+0x32/0x80 ? dotrap+0xd9/0x100 ? dqlcompleted+0x26b/0x290 ? dqlcompleted+0x26b/0x290 ? doerrortrap+0x6d/0xb0 ? dqlcompleted+0x26b/0x290 ? excinvalidop+0x4c/0x60 ? dqlcompleted+0x26b/0x290 ? asmexcinvalidop+0x16/0x20 ? dqlcompleted+0x26b/0x290 freeoldxmit+0xff/0x170 [virtionet] freeoldxmit+0x54/0xc0 [virtionet] virtnetpoll+0xf4/0xe30 [virtionet] ? updateloadavgcfsrq+0x264/0x2d0 ? updatecurr+0x35/0x260 ? reweightentity+0x1be/0x260 napipoll.constprop.0+0x28/0x1c0 netrxaction+0x329/0x420 ? enqueuehrtimer+0x35/0x90 ? tracehardirqson+0x1d/0x80 ? kvmschedclockread+0xd/0x20 ? schedclock+0xc/0x30 ? kvmschedclockread+0xd/0x20 ? schedclock+0xc/0x30 ? schedclockcpu+0xd/0x1a0 handlesoftirqs+0x138/0x3e0 dosoftirq.part.0+0x89/0xc0 </IRQ> <TASK> localbhenableip+0xa7/0xb0 virtnetopen+0xc8/0x310 [virtionet] devopen+0xfa/0x1b0 devchangeflags+0x1de/0x250 devchangeflags+0x22/0x60 dosetlink.isra.0+0x2df/0x10b0 ? rtnetlinkrcvmsg+0x34f/0x3f0 ? netlinkrcvskb+0x54/0x100 ? netlinkunicas ---truncated---

Affected Software

4 affected componentsFixes available
Linux Linux kernel>=6.11<6.12.6
Linux Linux kernel=6.13-rc1
Linux Linux kernel=6.13-rc2
debian/linux
5.10.223-15.10.234-16.1.129-16.1.133-16.12.21-16.12.22-1

Event History

Dec 27, 2024
CVE Published
via MITRE·03:06 PM
Data Sourced
via MITRE·03:06 PM
Description
Data Sourced
via NVD·03:15 PM
RemedyDescriptionSeverityWeaknessAffected Software
Apr 13, 2025
Data Sourced
via Ubuntu·01:08 AM
RemedyDescriptionSeverityAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2024-56674?

The severity of CVE-2024-56674 is classified as medium due to its potential impact on network operations.

2

How do I fix CVE-2024-56674?

To fix CVE-2024-56674, update your Linux kernel to version 6.12.6 or later.

3

Which versions of the Linux kernel are affected by CVE-2024-56674?

CVE-2024-56674 affects Linux kernel versions between 6.11 and 6.12.6, as well as versions 6.13-rc1 and 6.13-rc2.

4

What does CVE-2024-56674 involve?

CVE-2024-56674 involves a vulnerability in the Linux kernel's virtio_net subsystem related to the netdev_tx_reset_queue invocation point.

5

Is there a workaround for CVE-2024-56674 if I can't immediately update?

There are no known workarounds for CVE-2024-56674, so updating the kernel is recommended.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203