CVE-2024-56674 (GCVE-0-2024-56674)

Vulnerability from cvelistv5 – Published: 2024-12-27 15:06 – Updated: 2026-05-11 20:57
VLAI
Title
virtio_net: correct netdev_tx_reset_queue() invocation point
Summary
In the Linux kernel, the following vulnerability has been resolved: virtio_net: correct netdev_tx_reset_queue() invocation point When virtnet_close is followed by virtnet_open, some TX completions can possibly remain unconsumed, until they are finally processed during the first NAPI poll after the netdev_tx_reset_queue(), resulting in a crash [1]. Commit b96ed2c97c79 ("virtio_net: move netdev_tx_reset_queue() 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. netdev_tx_reset_queue() can actually be dropped from virtnet_open 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 virtnet_close could somehow lead to some TX completions delayed for long, followed by virtnet_open, 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 stall_max via sysfs. So, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This eliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now explicitly required in freeze/restore path. This patch adds it to immediately after free_unused_bufs(), following the rule of thumb: netdev_tx_reset_queue() should follow any SKB freeing not followed by netdev_tx_completed_queue(). This seems the most consistent and streamlined approach, and now netdev_tx_reset_queue() runs whenever free_unused_bufs() is done. [1]: ------------[ cut here ]------------ kernel BUG at lib/dynamic_queue_limits.c:99! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G N 6.12.0net-next_main+ #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:dql_completed+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 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? dql_completed+0x26b/0x290 ? exc_invalid_op+0x4c/0x60 ? dql_completed+0x26b/0x290 ? asm_exc_invalid_op+0x16/0x20 ? dql_completed+0x26b/0x290 __free_old_xmit+0xff/0x170 [virtio_net] free_old_xmit+0x54/0xc0 [virtio_net] virtnet_poll+0xf4/0xe30 [virtio_net] ? __update_load_avg_cfs_rq+0x264/0x2d0 ? update_curr+0x35/0x260 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? sched_clock_cpu+0xd/0x1a0 handle_softirqs+0x138/0x3e0 do_softirq.part.0+0x89/0xc0 </IRQ> <TASK> __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicas ---truncated---
Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-672 - Operation on a Resource after Expiration or Release
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01 , < b4294d4ac61fbb382811a1d64eaf81f446ce2af4 (git)
Affected: c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01 , < 3ddccbefebdbe0c4c72a248676e4d39ac66a8e26 (git)
Create a notification for this product.
Linux Linux Affected: 6.11
Unaffected: 0 , < 6.11 (semver)
Unaffected: 6.12.6 , ≤ 6.12.* (semver)
Unaffected: 6.13 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 5.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2024-56674",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-10-01T19:59:28.018357Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-672",
                "description": "CWE-672 Operation on a Resource after Expiration or Release",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-10-01T20:07:08.807Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/virtio_net.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "b4294d4ac61fbb382811a1d64eaf81f446ce2af4",
              "status": "affected",
              "version": "c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01",
              "versionType": "git"
            },
            {
              "lessThan": "3ddccbefebdbe0c4c72a248676e4d39ac66a8e26",
              "status": "affected",
              "version": "c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/virtio_net.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.11"
            },
            {
              "lessThan": "6.11",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.6",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13",
                  "versionStartIncluding": "6.11",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: correct netdev_tx_reset_queue() invocation point\n\nWhen virtnet_close is followed by virtnet_open, some TX completions can\npossibly remain unconsumed, until they are finally processed during the\nfirst NAPI poll after the netdev_tx_reset_queue(), resulting in a crash\n[1]. Commit b96ed2c97c79 (\"virtio_net: move netdev_tx_reset_queue() call\nbefore RX napi enable\") was not sufficient to eliminate all BQL crash\ncases for virtio-net.\n\nThis issue can be reproduced with the latest net-next master by running:\n`while :; do ip l set DEV down; ip l set DEV up; done` under heavy network\nTX load from inside the machine.\n\nnetdev_tx_reset_queue() can actually be dropped from virtnet_open path;\nthe device is not stopped in any case. For BQL core part, it\u0027s just like\ntraffic nearly ceases to exist for some period. For stall detector added\nto BQL, even if virtnet_close could somehow lead to some TX completions\ndelayed for long, followed by virtnet_open, we can just take it as stall\nas mentioned in commit 6025b9135f7a (\"net: dqs: add NIC stall detector\nbased on BQL\"). Note also that users can still reset stall_max via sysfs.\n\nSo, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This\neliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now\nexplicitly required in freeze/restore path. This patch adds it to\nimmediately after free_unused_bufs(), following the rule of thumb:\nnetdev_tx_reset_queue() should follow any SKB freeing not followed by\nnetdev_tx_completed_queue(). This seems the most consistent and\nstreamlined approach, and now netdev_tx_reset_queue() runs whenever\nfree_unused_bufs() is done.\n\n[1]:\n------------[ cut here ]------------\nkernel BUG at lib/dynamic_queue_limits.c:99!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G    N 6.12.0net-next_main+ #2\nTainted: [N]=TEST\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), \\\nBIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:dql_completed+0x26b/0x290\nCode: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d\n4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff \u003c0f\u003e 0b 01\nd2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff\nRSP: 0018:ffffc900002b0d08 EFLAGS: 00010297\nRAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009\nRDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000\nRBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000\nR10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001\nR13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40\nFS:  00007f41ded69500(0000) GS:ffff888667dc0000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0\nPKRU: 55555554\nCall Trace:\n \u003cIRQ\u003e\n ? die+0x32/0x80\n ? do_trap+0xd9/0x100\n ? dql_completed+0x26b/0x290\n ? dql_completed+0x26b/0x290\n ? do_error_trap+0x6d/0xb0\n ? dql_completed+0x26b/0x290\n ? exc_invalid_op+0x4c/0x60\n ? dql_completed+0x26b/0x290\n ? asm_exc_invalid_op+0x16/0x20\n ? dql_completed+0x26b/0x290\n __free_old_xmit+0xff/0x170 [virtio_net]\n free_old_xmit+0x54/0xc0 [virtio_net]\n virtnet_poll+0xf4/0xe30 [virtio_net]\n ? __update_load_avg_cfs_rq+0x264/0x2d0\n ? update_curr+0x35/0x260\n ? reweight_entity+0x1be/0x260\n __napi_poll.constprop.0+0x28/0x1c0\n net_rx_action+0x329/0x420\n ? enqueue_hrtimer+0x35/0x90\n ? trace_hardirqs_on+0x1d/0x80\n ? kvm_sched_clock_read+0xd/0x20\n ? sched_clock+0xc/0x30\n ? kvm_sched_clock_read+0xd/0x20\n ? sched_clock+0xc/0x30\n ? sched_clock_cpu+0xd/0x1a0\n handle_softirqs+0x138/0x3e0\n do_softirq.part.0+0x89/0xc0\n \u003c/IRQ\u003e\n \u003cTASK\u003e\n __local_bh_enable_ip+0xa7/0xb0\n virtnet_open+0xc8/0x310 [virtio_net]\n __dev_open+0xfa/0x1b0\n __dev_change_flags+0x1de/0x250\n dev_change_flags+0x22/0x60\n do_setlink.isra.0+0x2df/0x10b0\n ? rtnetlink_rcv_msg+0x34f/0x3f0\n ? netlink_rcv_skb+0x54/0x100\n ? netlink_unicas\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:57:04.165Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/b4294d4ac61fbb382811a1d64eaf81f446ce2af4"
        },
        {
          "url": "https://git.kernel.org/stable/c/3ddccbefebdbe0c4c72a248676e4d39ac66a8e26"
        }
      ],
      "title": "virtio_net: correct netdev_tx_reset_queue() invocation point",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-56674",
    "datePublished": "2024-12-27T15:06:35.160Z",
    "dateReserved": "2024-12-27T15:00:39.845Z",
    "dateUpdated": "2026-05-11T20:57:04.165Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-56674",
      "date": "2026-07-22",
      "epss": "0.00199",
      "percentile": "0.10006"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.11\", \"versionEndExcluding\": \"6.12.6\", \"matchCriteriaId\": \"97C759FD-3999-4EA7-B961-1CADF641F560\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*\", \"matchCriteriaId\": \"62567B3C-6CEE-46D0-BC2E-B3717FBF7D13\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:*\", \"matchCriteriaId\": \"5A073481-106D-4B15-B4C7-FB0213B8E1D4\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nvirtio_net: correct netdev_tx_reset_queue() invocation point\\n\\nWhen virtnet_close is followed by virtnet_open, some TX completions can\\npossibly remain unconsumed, until they are finally processed during the\\nfirst NAPI poll after the netdev_tx_reset_queue(), resulting in a crash\\n[1]. Commit b96ed2c97c79 (\\\"virtio_net: move netdev_tx_reset_queue() call\\nbefore RX napi enable\\\") was not sufficient to eliminate all BQL crash\\ncases for virtio-net.\\n\\nThis issue can be reproduced with the latest net-next master by running:\\n`while :; do ip l set DEV down; ip l set DEV up; done` under heavy network\\nTX load from inside the machine.\\n\\nnetdev_tx_reset_queue() can actually be dropped from virtnet_open path;\\nthe device is not stopped in any case. For BQL core part, it\u0027s just like\\ntraffic nearly ceases to exist for some period. For stall detector added\\nto BQL, even if virtnet_close could somehow lead to some TX completions\\ndelayed for long, followed by virtnet_open, we can just take it as stall\\nas mentioned in commit 6025b9135f7a (\\\"net: dqs: add NIC stall detector\\nbased on BQL\\\"). Note also that users can still reset stall_max via sysfs.\\n\\nSo, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This\\neliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now\\nexplicitly required in freeze/restore path. This patch adds it to\\nimmediately after free_unused_bufs(), following the rule of thumb:\\nnetdev_tx_reset_queue() should follow any SKB freeing not followed by\\nnetdev_tx_completed_queue(). This seems the most consistent and\\nstreamlined approach, and now netdev_tx_reset_queue() runs whenever\\nfree_unused_bufs() is done.\\n\\n[1]:\\n------------[ cut here ]------------\\nkernel BUG at lib/dynamic_queue_limits.c:99!\\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\\nCPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G    N 6.12.0net-next_main+ #2\\nTainted: [N]=TEST\\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), \\\\\\nBIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\\nRIP: 0010:dql_completed+0x26b/0x290\\nCode: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d\\n4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff \u003c0f\u003e 0b 01\\nd2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff\\nRSP: 0018:ffffc900002b0d08 EFLAGS: 00010297\\nRAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009\\nRDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000\\nRBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000\\nR10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001\\nR13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40\\nFS:  00007f41ded69500(0000) GS:ffff888667dc0000(0000)\\nknlGS:0000000000000000\\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\nCR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0\\nPKRU: 55555554\\nCall Trace:\\n \u003cIRQ\u003e\\n ? die+0x32/0x80\\n ? do_trap+0xd9/0x100\\n ? dql_completed+0x26b/0x290\\n ? dql_completed+0x26b/0x290\\n ? do_error_trap+0x6d/0xb0\\n ? dql_completed+0x26b/0x290\\n ? exc_invalid_op+0x4c/0x60\\n ? dql_completed+0x26b/0x290\\n ? asm_exc_invalid_op+0x16/0x20\\n ? dql_completed+0x26b/0x290\\n __free_old_xmit+0xff/0x170 [virtio_net]\\n free_old_xmit+0x54/0xc0 [virtio_net]\\n virtnet_poll+0xf4/0xe30 [virtio_net]\\n ? __update_load_avg_cfs_rq+0x264/0x2d0\\n ? update_curr+0x35/0x260\\n ? reweight_entity+0x1be/0x260\\n __napi_poll.constprop.0+0x28/0x1c0\\n net_rx_action+0x329/0x420\\n ? enqueue_hrtimer+0x35/0x90\\n ? trace_hardirqs_on+0x1d/0x80\\n ? kvm_sched_clock_read+0xd/0x20\\n ? sched_clock+0xc/0x30\\n ? kvm_sched_clock_read+0xd/0x20\\n ? sched_clock+0xc/0x30\\n ? sched_clock_cpu+0xd/0x1a0\\n handle_softirqs+0x138/0x3e0\\n do_softirq.part.0+0x89/0xc0\\n \u003c/IRQ\u003e\\n \u003cTASK\u003e\\n __local_bh_enable_ip+0xa7/0xb0\\n virtnet_open+0xc8/0x310 [virtio_net]\\n __dev_open+0xfa/0x1b0\\n __dev_change_flags+0x1de/0x250\\n dev_change_flags+0x22/0x60\\n do_setlink.isra.0+0x2df/0x10b0\\n ? rtnetlink_rcv_msg+0x34f/0x3f0\\n ? netlink_rcv_skb+0x54/0x100\\n ? netlink_unicas\\n---truncated---\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: punto de invocaci\\u00f3n correcto de netdev_tx_reset_queue() Cuando virtnet_close es seguido por virtnet_open, es posible que algunas finalizaciones de TX permanezcan sin consumir, hasta que finalmente se procesen durante el primer sondeo NAPI despu\\u00e9s de netdev_tx_reset_queue(), lo que resulta en un bloqueo [1]. el commit b96ed2c97c79 (\\\"virtio_net: mover la llamada netdev_tx_reset_queue() antes de la habilitaci\\u00f3n de napi RX\\\") no fue suficiente para eliminar todos los casos de bloqueo de BQL para virtio-net. Este problema se puede reproducir con el \\u00faltimo maestro net-next ejecutando: `while :; do ip l set DEV down; ip l set DEV up; done` bajo una carga de TX de red pesada desde el interior de la m\\u00e1quina. netdev_tx_reset_queue() en realidad se puede eliminar de la ruta virtnet_open; el dispositivo no se detiene en ning\\u00fan caso. Para la parte principal de BQL, es como si el tr\\u00e1fico casi dejara de existir durante un per\\u00edodo. Para el detector de bloqueo agregado a BQL, incluso si virtnet_close pudiera de alguna manera provocar que algunas finalizaciones de TX se retrasaran durante mucho tiempo, seguido de virtnet_open, podemos simplemente tomarlo como un bloqueo como se menciona en el commit 6025b9135f7a (\\\"net: dqs: agregar detector de bloqueo de NIC basado en BQL\\\"). Tenga en cuenta tambi\\u00e9n que los usuarios a\\u00fan pueden restablecer stall_max a trav\\u00e9s de sysfs. Por lo tanto, elimine netdev_tx_reset_queue() de virtnet_enable_queue_pair(). Esto elimina los bloqueos de BQL. Como resultado, netdev_tx_reset_queue() ahora se requiere expl\\u00edcitamente en la ruta de congelamiento/restauraci\\u00f3n. Este parche lo agrega inmediatamente despu\\u00e9s de free_unused_bufs(), siguiendo la regla general: netdev_tx_reset_queue() debe seguir cualquier liberaci\\u00f3n de SKB no seguida por netdev_tx_completed_queue(). Este parece ser el enfoque m\\u00e1s consistente y optimizado, y ahora netdev_tx_reset_queue() se ejecuta siempre que se realiza free_unused_bufs(). [1]: ------------[ corte aqu\\u00ed ]------------ \\u00a1ERROR del kernel en lib/dynamic_queue_limits.c:99! Oops: c\\u00f3digo de operaci\\u00f3n no v\\u00e1lido: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Contaminado: GN 6.12.0net-next_main+ #2 Contaminado: [N]=TEST Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), \\\\ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dql_completed+0x26b/0x290 C\\u00f3digo: 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 \u0026lt;0f\u0026gt; 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: 00000000000000000 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 Rastreo de llamadas:  ? die+0x32/0x80 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? __actualizar_carga_avg_cfs_rq+0x264/0x2d0 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ?  __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicas ---truncado---\"}]",
      "id": "CVE-2024-56674",
      "lastModified": "2025-01-06T15:06:43.330",
      "metrics": "{\"cvssMetricV31\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"baseScore\": 5.5, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"LOCAL\", \"attackComplexity\": \"LOW\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"HIGH\"}, \"exploitabilityScore\": 1.8, \"impactScore\": 3.6}]}",
      "published": "2024-12-27T15:15:27.313",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/3ddccbefebdbe0c4c72a248676e4d39ac66a8e26\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/b4294d4ac61fbb382811a1d64eaf81f446ce2af4\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Analyzed",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-672\"}]}]"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-56674\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-12-27T15:15:27.313\",\"lastModified\":\"2026-06-17T08:12:43.050\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nvirtio_net: correct netdev_tx_reset_queue() invocation point\\n\\nWhen virtnet_close is followed by virtnet_open, some TX completions can\\npossibly remain unconsumed, until they are finally processed during the\\nfirst NAPI poll after the netdev_tx_reset_queue(), resulting in a crash\\n[1]. Commit b96ed2c97c79 (\\\"virtio_net: move netdev_tx_reset_queue() call\\nbefore RX napi enable\\\") was not sufficient to eliminate all BQL crash\\ncases for virtio-net.\\n\\nThis issue can be reproduced with the latest net-next master by running:\\n`while :; do ip l set DEV down; ip l set DEV up; done` under heavy network\\nTX load from inside the machine.\\n\\nnetdev_tx_reset_queue() can actually be dropped from virtnet_open path;\\nthe device is not stopped in any case. For BQL core part, it\u0027s just like\\ntraffic nearly ceases to exist for some period. For stall detector added\\nto BQL, even if virtnet_close could somehow lead to some TX completions\\ndelayed for long, followed by virtnet_open, we can just take it as stall\\nas mentioned in commit 6025b9135f7a (\\\"net: dqs: add NIC stall detector\\nbased on BQL\\\"). Note also that users can still reset stall_max via sysfs.\\n\\nSo, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This\\neliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now\\nexplicitly required in freeze/restore path. This patch adds it to\\nimmediately after free_unused_bufs(), following the rule of thumb:\\nnetdev_tx_reset_queue() should follow any SKB freeing not followed by\\nnetdev_tx_completed_queue(). This seems the most consistent and\\nstreamlined approach, and now netdev_tx_reset_queue() runs whenever\\nfree_unused_bufs() is done.\\n\\n[1]:\\n------------[ cut here ]------------\\nkernel BUG at lib/dynamic_queue_limits.c:99!\\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\\nCPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G    N 6.12.0net-next_main+ #2\\nTainted: [N]=TEST\\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), \\\\\\nBIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\\nRIP: 0010:dql_completed+0x26b/0x290\\nCode: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d\\n4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff \u003c0f\u003e 0b 01\\nd2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff\\nRSP: 0018:ffffc900002b0d08 EFLAGS: 00010297\\nRAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009\\nRDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000\\nRBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000\\nR10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001\\nR13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40\\nFS:  00007f41ded69500(0000) GS:ffff888667dc0000(0000)\\nknlGS:0000000000000000\\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\nCR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0\\nPKRU: 55555554\\nCall Trace:\\n \u003cIRQ\u003e\\n ? die+0x32/0x80\\n ? do_trap+0xd9/0x100\\n ? dql_completed+0x26b/0x290\\n ? dql_completed+0x26b/0x290\\n ? do_error_trap+0x6d/0xb0\\n ? dql_completed+0x26b/0x290\\n ? exc_invalid_op+0x4c/0x60\\n ? dql_completed+0x26b/0x290\\n ? asm_exc_invalid_op+0x16/0x20\\n ? dql_completed+0x26b/0x290\\n __free_old_xmit+0xff/0x170 [virtio_net]\\n free_old_xmit+0x54/0xc0 [virtio_net]\\n virtnet_poll+0xf4/0xe30 [virtio_net]\\n ? __update_load_avg_cfs_rq+0x264/0x2d0\\n ? update_curr+0x35/0x260\\n ? reweight_entity+0x1be/0x260\\n __napi_poll.constprop.0+0x28/0x1c0\\n net_rx_action+0x329/0x420\\n ? enqueue_hrtimer+0x35/0x90\\n ? trace_hardirqs_on+0x1d/0x80\\n ? kvm_sched_clock_read+0xd/0x20\\n ? sched_clock+0xc/0x30\\n ? kvm_sched_clock_read+0xd/0x20\\n ? sched_clock+0xc/0x30\\n ? sched_clock_cpu+0xd/0x1a0\\n handle_softirqs+0x138/0x3e0\\n do_softirq.part.0+0x89/0xc0\\n \u003c/IRQ\u003e\\n \u003cTASK\u003e\\n __local_bh_enable_ip+0xa7/0xb0\\n virtnet_open+0xc8/0x310 [virtio_net]\\n __dev_open+0xfa/0x1b0\\n __dev_change_flags+0x1de/0x250\\n dev_change_flags+0x22/0x60\\n do_setlink.isra.0+0x2df/0x10b0\\n ? rtnetlink_rcv_msg+0x34f/0x3f0\\n ? netlink_rcv_skb+0x54/0x100\\n ? netlink_unicas\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: punto de invocaci\u00f3n correcto de netdev_tx_reset_queue() Cuando virtnet_close es seguido por virtnet_open, es posible que algunas finalizaciones de TX permanezcan sin consumir, hasta que finalmente se procesen durante el primer sondeo NAPI despu\u00e9s de netdev_tx_reset_queue(), lo que resulta en un bloqueo [1]. el commit b96ed2c97c79 (\\\"virtio_net: mover la llamada netdev_tx_reset_queue() antes de la habilitaci\u00f3n de napi RX\\\") no fue suficiente para eliminar todos los casos de bloqueo de BQL para virtio-net. Este problema se puede reproducir con el \u00faltimo maestro net-next ejecutando: `while :; do ip l set DEV down; ip l set DEV up; done` bajo una carga de TX de red pesada desde el interior de la m\u00e1quina. netdev_tx_reset_queue() en realidad se puede eliminar de la ruta virtnet_open; el dispositivo no se detiene en ning\u00fan caso. Para la parte principal de BQL, es como si el tr\u00e1fico casi dejara de existir durante un per\u00edodo. Para el detector de bloqueo agregado a BQL, incluso si virtnet_close pudiera de alguna manera provocar que algunas finalizaciones de TX se retrasaran durante mucho tiempo, seguido de virtnet_open, podemos simplemente tomarlo como un bloqueo como se menciona en el commit 6025b9135f7a (\\\"net: dqs: agregar detector de bloqueo de NIC basado en BQL\\\"). Tenga en cuenta tambi\u00e9n que los usuarios a\u00fan pueden restablecer stall_max a trav\u00e9s de sysfs. Por lo tanto, elimine netdev_tx_reset_queue() de virtnet_enable_queue_pair(). Esto elimina los bloqueos de BQL. Como resultado, netdev_tx_reset_queue() ahora se requiere expl\u00edcitamente en la ruta de congelamiento/restauraci\u00f3n. Este parche lo agrega inmediatamente despu\u00e9s de free_unused_bufs(), siguiendo la regla general: netdev_tx_reset_queue() debe seguir cualquier liberaci\u00f3n de SKB no seguida por netdev_tx_completed_queue(). Este parece ser el enfoque m\u00e1s consistente y optimizado, y ahora netdev_tx_reset_queue() se ejecuta siempre que se realiza free_unused_bufs(). [1]: ------------[ corte aqu\u00ed ]------------ \u00a1ERROR del kernel en lib/dynamic_queue_limits.c:99! Oops: c\u00f3digo de operaci\u00f3n no v\u00e1lido: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Contaminado: GN 6.12.0net-next_main+ #2 Contaminado: [N]=TEST Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), \\\\ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dql_completed+0x26b/0x290 C\u00f3digo: 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 \u0026lt;0f\u0026gt; 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: 00000000000000000 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 Rastreo de llamadas:  ? die+0x32/0x80 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? __actualizar_carga_avg_cfs_rq+0x264/0x2d0 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ?  __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicas ---truncado---\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/net/virtio_net.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01\",\"lessThan\":\"b4294d4ac61fbb382811a1d64eaf81f446ce2af4\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01\",\"lessThan\":\"3ddccbefebdbe0c4c72a248676e4d39ac66a8e26\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/net/virtio_net.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"6.11\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.11\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.6\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.13\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2025-10-01T19:59:28.018357Z\",\"id\":\"CVE-2024-56674\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-672\"}]},{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-672\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.11\",\"versionEndExcluding\":\"6.12.6\",\"matchCriteriaId\":\"97C759FD-3999-4EA7-B961-1CADF641F560\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"62567B3C-6CEE-46D0-BC2E-B3717FBF7D13\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"5A073481-106D-4B15-B4C7-FB0213B8E1D4\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/3ddccbefebdbe0c4c72a248676e4d39ac66a8e26\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b4294d4ac61fbb382811a1d64eaf81f446ce2af4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2025-11-21T13:51:37+00:00",
      "cve": "CVE-2024-56674",
      "id": "CVE-2024-56674",
      "initial_release_date": "2024-12-27T00:00:00+00:00",
      "product_status:known_affected": "42",
      "product_status:known_not_affected": "156",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: virtio_net: correct netdev_tx_reset_queue() invocation point",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56674.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-07-15T19:15:35Z",
      "cve": "CVE-2024-56674",
      "id": "CVE-2024-56674",
      "initial_release_date": "2025-01-12T00:14:48Z",
      "product_status:known_not_affected": "423",
      "product_status:recommended": "26",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2024-56674",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-56674.json",
      "version": "18"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.5, \"attackVector\": \"LOCAL\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"NONE\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-56674\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-10-01T19:59:28.018357Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-672\", \"description\": \"CWE-672 Operation on a Resource after Expiration or Release\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-10-01T15:46:09.897Z\"}}], \"cna\": {\"title\": \"virtio_net: correct netdev_tx_reset_queue() invocation point\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01\", \"lessThan\": \"b4294d4ac61fbb382811a1d64eaf81f446ce2af4\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01\", \"lessThan\": \"3ddccbefebdbe0c4c72a248676e4d39ac66a8e26\", \"versionType\": \"git\"}], \"programFiles\": [\"drivers/net/virtio_net.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"6.11\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"6.11\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.12.6\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.12.*\"}, {\"status\": \"unaffected\", \"version\": \"6.13\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"drivers/net/virtio_net.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/b4294d4ac61fbb382811a1d64eaf81f446ce2af4\"}, {\"url\": \"https://git.kernel.org/stable/c/3ddccbefebdbe0c4c72a248676e4d39ac66a8e26\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nvirtio_net: correct netdev_tx_reset_queue() invocation point\\n\\nWhen virtnet_close is followed by virtnet_open, some TX completions can\\npossibly remain unconsumed, until they are finally processed during the\\nfirst NAPI poll after the netdev_tx_reset_queue(), resulting in a crash\\n[1]. Commit b96ed2c97c79 (\\\"virtio_net: move netdev_tx_reset_queue() call\\nbefore RX napi enable\\\") was not sufficient to eliminate all BQL crash\\ncases for virtio-net.\\n\\nThis issue can be reproduced with the latest net-next master by running:\\n`while :; do ip l set DEV down; ip l set DEV up; done` under heavy network\\nTX load from inside the machine.\\n\\nnetdev_tx_reset_queue() can actually be dropped from virtnet_open path;\\nthe device is not stopped in any case. For BQL core part, it\u0027s just like\\ntraffic nearly ceases to exist for some period. For stall detector added\\nto BQL, even if virtnet_close could somehow lead to some TX completions\\ndelayed for long, followed by virtnet_open, we can just take it as stall\\nas mentioned in commit 6025b9135f7a (\\\"net: dqs: add NIC stall detector\\nbased on BQL\\\"). Note also that users can still reset stall_max via sysfs.\\n\\nSo, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This\\neliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now\\nexplicitly required in freeze/restore path. This patch adds it to\\nimmediately after free_unused_bufs(), following the rule of thumb:\\nnetdev_tx_reset_queue() should follow any SKB freeing not followed by\\nnetdev_tx_completed_queue(). This seems the most consistent and\\nstreamlined approach, and now netdev_tx_reset_queue() runs whenever\\nfree_unused_bufs() is done.\\n\\n[1]:\\n------------[ cut here ]------------\\nkernel BUG at lib/dynamic_queue_limits.c:99!\\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\\nCPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G    N 6.12.0net-next_main+ #2\\nTainted: [N]=TEST\\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), \\\\\\nBIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\\nRIP: 0010:dql_completed+0x26b/0x290\\nCode: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d\\n4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff \u003c0f\u003e 0b 01\\nd2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff\\nRSP: 0018:ffffc900002b0d08 EFLAGS: 00010297\\nRAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009\\nRDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000\\nRBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000\\nR10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001\\nR13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40\\nFS:  00007f41ded69500(0000) GS:ffff888667dc0000(0000)\\nknlGS:0000000000000000\\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\nCR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0\\nPKRU: 55555554\\nCall Trace:\\n \u003cIRQ\u003e\\n ? die+0x32/0x80\\n ? do_trap+0xd9/0x100\\n ? dql_completed+0x26b/0x290\\n ? dql_completed+0x26b/0x290\\n ? do_error_trap+0x6d/0xb0\\n ? dql_completed+0x26b/0x290\\n ? exc_invalid_op+0x4c/0x60\\n ? dql_completed+0x26b/0x290\\n ? asm_exc_invalid_op+0x16/0x20\\n ? dql_completed+0x26b/0x290\\n __free_old_xmit+0xff/0x170 [virtio_net]\\n free_old_xmit+0x54/0xc0 [virtio_net]\\n virtnet_poll+0xf4/0xe30 [virtio_net]\\n ? __update_load_avg_cfs_rq+0x264/0x2d0\\n ? update_curr+0x35/0x260\\n ? reweight_entity+0x1be/0x260\\n __napi_poll.constprop.0+0x28/0x1c0\\n net_rx_action+0x329/0x420\\n ? enqueue_hrtimer+0x35/0x90\\n ? trace_hardirqs_on+0x1d/0x80\\n ? kvm_sched_clock_read+0xd/0x20\\n ? sched_clock+0xc/0x30\\n ? kvm_sched_clock_read+0xd/0x20\\n ? sched_clock+0xc/0x30\\n ? sched_clock_cpu+0xd/0x1a0\\n handle_softirqs+0x138/0x3e0\\n do_softirq.part.0+0x89/0xc0\\n \u003c/IRQ\u003e\\n \u003cTASK\u003e\\n __local_bh_enable_ip+0xa7/0xb0\\n virtnet_open+0xc8/0x310 [virtio_net]\\n __dev_open+0xfa/0x1b0\\n __dev_change_flags+0x1de/0x250\\n dev_change_flags+0x22/0x60\\n do_setlink.isra.0+0x2df/0x10b0\\n ? rtnetlink_rcv_msg+0x34f/0x3f0\\n ? netlink_rcv_skb+0x54/0x100\\n ? netlink_unicas\\n---truncated---\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.12.6\", \"versionStartIncluding\": \"6.11\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.13\", \"versionStartIncluding\": \"6.11\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-05-04T10:01:51.817Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-56674\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-10-01T20:07:08.807Z\", \"dateReserved\": \"2024-12-27T15:00:39.845Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-12-27T15:06:35.160Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.