{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2025-68169 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2025-68169 is a denial of service vulnerability in Linux, published on 16 Dec 2025. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2025-68169 and fix it if it is affected.\n\nWhat it is: CVE-2025-68169 is a denial of service vulnerability in Linux, published on 16 Dec 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2025-68169 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2025-68169/ (Markdown: https://insights.sbomify.com/CVE-2025-68169/index.md)","id":"CVE-2025-68169","markdown":"https://insights.sbomify.com/CVE-2025-68169/index.md","name":"CVE-2025-68169","record":{"aliases":["BELL-CVE-2025-68169","CLEANSTART-2026-GH39701","DEBIAN-CVE-2025-68169","GHSA-x9w7-p4vp-q593","UBUNTU-CVE-2025-68169"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"Linux kernel","requires_auth":"none","summary":"A deadlock in the Linux kernel netpoll subsystem can cause a system hang when memory allocation fails under pressure, leading to denial of service.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetpoll: Fix deadlock in memory allocation under spinlock\n\nFix a AA deadlock in refill_skbs() where memory allocation while holding\nskb_pool-\u003elock can trigger a recursive lock acquisition attempt.\n\nThe deadlock scenario occurs when the system is under severe memory\npressure:\n\n1. refill_skbs() acquires skb_pool-\u003elock (spinlock)\n2. alloc_skb() is called while holding the lock\n3. Memory allocator fails and calls slab_out_of_memory()\n4. This triggers printk() for the OOM warning\n5. The console output path calls netpoll_send_udp()\n6. netpoll_send_udp() attempts to acquire the same skb_pool-\u003elock\n7. Deadlock: the lock is already held by the same CPU\n\nCall stack:\n  refill_skbs()\n    spin_lock_irqsave(\u0026skb_pool-\u003elock)    \u003c- lock acquired\n    __alloc_skb()\n      kmem_cache_alloc_node_noprof()\n        slab_out_of_memory()\n          printk()\n            console_flush_all()\n              netpoll_send_udp()\n                skb_dequeue()\n                  spin_lock_irqsave(\u0026skb_pool-\u003elock)     \u003c- deadlock attempt\n\nThis bug was exposed by commit 248f6571fd4c51 (\"netpoll: Optimize skb\nrefilling on critical path\") which removed refill_skbs() from the\ncritical path (where nested printk was being deferred), letting nested\nprintk being called from inside refill_skbs()\n\nRefactor refill_skbs() to never allocate memory while holding\nthe spinlock.\n\nAnother possible solution to fix this problem is protecting the\nrefill_skbs() from nested printks, basically calling\nprintk_deferred_{enter,exit}() in refill_skbs(), then, any nested\npr_warn() would be deferred.\n\nI prefer this approach, given I _think_ it might be a good idea to move\nthe alloc_skb() from GFP_ATOMIC to GFP_KERNEL in the future, so, having\nthe alloc_skb() outside of the lock will be necessary step.\n\nThere is a possible TOCTOU issue when checking for the pool length, and\nqueueing the new allocated skb, but, this is not an issue, given that\nan extra SKB in the pool is harmless and it will be eventually used.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"netpoll: Fix deadlock in memory allocation under spinlock","id":"CVE-2025-68169","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2025"},"n_packages":0,"n_references":2,"next":{"headline":"drm/radeon: Do not kfree() devres managed rdev","id":"CVE-2025-68170"},"packages":[],"prev":{"headline":"jfs: fix uninitialized waitqueue in transaction manager","id":"CVE-2025-68168"},"products":["Linux"],"published":"2025-12-16","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A deadlock in the Linux kernel netpoll subsystem can cause a system hang when memory allocation fails under pressure, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2025-68169/"}