{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-44995", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-44995" ], "published": "2024-09-04T19:57:01Z", "summary": "net: hns3: fix a deadlock problem when config TC during resetting", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix a deadlock problem when config TC during resetting\n\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n pf reset start\n \u2502\n \u25bc\n ......\nsetup tc \u2502\n \u2502 \u25bc\n \u25bc DOWN: napi_disable()\nnapi_disable()(skip) \u2502\n \u2502 \u2502\n \u25bc \u25bc\n ...... ......\n \u2502 \u2502\n \u25bc \u2502\nnapi_enable() \u2502\n \u25bc\n UINIT: netif_napi_del()\n \u2502\n \u25bc\n ......\n \u2502\n \u25bc\n INIT: netif_napi_add()\n \u2502\n \u25bc\n ...... global reset start\n \u2502 \u2502\n \u25bc \u25bc\n UP: napi_enable()(skip) ......\n \u2502 \u2502\n \u25bc \u25bc\n ...... napi_disable()\n\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.107", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-44995" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ced30a109" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerability is reached through local configuration interfaces \u2014 rtnetlink `RTM_NEWQDISC` (mqprio offload \u2192 `hns3_nic_setup_tc`) raced against an `ethtool --reset` / `ethtool -L` triggered PF reset. No remote peer input reaches this path, so it requires local access to the host.\nAC:L - The attacker controls both halves of the race: they start the PF reset themselves via `ethtool -r`, and `hclge_reset()` drops rtnl_lock for the entire hardware-reset wait, leaving a long, deterministic window in which the tc/mqprio ioctl can be issued in a tight loop until it lands. `hclge_setup_tc()` has no reset-state guard at all, so no condition outside the attacker's control is involved.\nPR:L - Both triggers (tc qdisc/mqprio and ethtool reset) require only CAP_NET_ADMIN over the hns3 netdevice, which is a delegatable capability held by unprivileged network-management daemons and by the owner of a user namespace whose network namespace holds the device (a dedicated PF handed to a container). This is not full root in the initial namespace, so Low rather than High.\nUI:N - The attacker issues both the reset request and the TC configuration themselves; no action by any other user or administrator is needed.\nS:U - The corruption and the hang are confined to the kernel of the same host, within the same security authority \u2014 there is no hypervisor, IOMMU, or sandbox boundary crossed.\nC:H - Because the missing `hns3_nic_net_stop()` lets `hns3_reset_notify_uninit_enet()` run against a live port, `devm_kfree(priv->tqp_vector)` and `hns3_uninit_all_ring()` free the NAPI contexts, DIM work items and DMA descriptor buffers while NAPI polling, pending DIM works and hardware DMA are still using them. The resulting use-after-free over freed, reallocatable slab memory can be leveraged to read attacker-chosen kernel data.\nI:H - The same use-after-free gives a write primitive \u2014 the uncancelled `rx_group.dim.work`/`tx_group.dim.work` execute against the freed `tqp_vector`, and the NIC continues DMA-writing into freed ring buffers, so heap-sprayed objects can be corrupted, which is exploitable toward control-flow hijack.\nA:H - The documented outcome is a permanent deadlock: `napi_disable()` spins forever on a NAPI that was re-added but never enabled, and it does so while the reset worker holds rtnl_lock, wedging every subsequent network-configuration operation on the machine plus the NIC itself. Any kernel hang/deadlock is High." } } }