{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-35970 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-35970 is a medium-severity vulnerability in Linux kernel, published on 20 May 2024. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2024-35970 and fix it if it is affected.\n\nWhat it is: CVE-2024-35970 is a medium-severity vulnerability in Linux kernel, published on 20 May 2024. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2024-35970 in the wild and no public exploit code.\n\nAffected product: Linux kernel. 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-2024-35970/ (Markdown: https://insights.sbomify.com/CVE-2024-35970/index.md)","id":"CVE-2024-35970","markdown":"https://insights.sbomify.com/CVE-2024-35970/index.md","name":"CVE-2024-35970","record":{"aliases":["A-432804305","ASB-A-432804305","BELL-CVE-2024-35970","DEBIAN-CVE-2024-35970","GHSA-p8xf-2w27-6wqx","UBUNTU-CVE-2024-35970"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel's AF_UNIX socket handling can cause a deadlock, leading to a denial of service.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":6.3,"severity":"medium","source":"cisa-adp","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L","version":"3.1"},"cwes":[{"id":"CWE-667","name":"Improper Locking"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Clear stale u-\u003eoob_skb.\n\nsyzkaller started to report deadlock of unix_gc_lock after commit\n4090fa373f0e (\"af_unix: Replace garbage collection algorithm.\"), but\nit just uncovers the bug that has been there since commit 314001f0bf92\n(\"af_unix: Add OOB support\").\n\nThe repro basically does the following.\n\n  from socket import *\n  from array import array\n\n  c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)\n  c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array(\"i\", [c2.fileno()]))], MSG_OOB)\n  c2.recv(1)  # blocked as no normal data in recv queue\n\n  c2.close()  # done async and unblock recv()\n  c1.close()  # done async and trigger GC\n\nA socket sends its file descriptor to itself as OOB data and tries to\nreceive normal data, but finally recv() fails due to async close().\n\nThe problem here is wrong handling of OOB skb in manage_oob().  When\nrecvmsg() is called without MSG_OOB, manage_oob() is called to check\nif the peeked skb is OOB skb.  In such a case, manage_oob() pops it\nout of the receive queue but does not clear unix_sock(sk)-\u003eoob_skb.\nThis is wrong in terms of uAPI.\n\nLet's say we send \"hello\" with MSG_OOB, and \"world\" without MSG_OOB.\nThe 'o' is handled as OOB data.  When recv() is called twice without\nMSG_OOB, the OOB data should be lost.\n\n  \u003e\u003e\u003e from socket import *\n  \u003e\u003e\u003e c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)\n  \u003e\u003e\u003e c1.send(b'hello', MSG_OOB)  # 'o' is OOB data\n  5\n  \u003e\u003e\u003e c1.send(b'world')\n  5\n  \u003e\u003e\u003e c2.recv(5)  # OOB data is not received\n  b'hell'\n  \u003e\u003e\u003e c2.recv(5)  # OOB date is skipped\n  b'world'\n  \u003e\u003e\u003e c2.recv(5, MSG_OOB)  # This should return an error\n  b'o'\n\nIn the same situation, TCP actually returns -EINVAL for the last\nrecv().\n\nAlso, if we do not clear unix_sk(sk)-\u003eoob_skb, unix_poll() always set\nEPOLLPRI even though the data has passed through by previous recv().\n\nTo avoid these issues, we must clear unix_sk(sk)-\u003eoob_skb when dequeuing\nit from recv queue.\n\nThe reason why the old GC did not trigger the deadlock is because the\nold GC relied on the receive queue to detect the loop.\n\nWhen it is triggered, the socket with OOB data is marked as GC candidate\nbecause file refcount == inflight count (1).  However, after traversing\nall inflight sockets, the socket still has a positive inflight count (1),\nthus the socket is excluded from candidates.  Then, the old GC lose the\nchance to garbage-collect the socket.\n\nWith the old GC, the repro continues to create true garbage that will\nnever be freed nor detected by kmemleak as it's linked to the global\ninflight list.  That's why we couldn't even notice the issue.","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":"af_unix: Clear stale u-\u003eoob_skb.","id":"CVE-2024-35970","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"race_condition","year":"2024"},"n_packages":0,"n_references":5,"next":{"headline":"net: ks8851: Handle softirqs at the end of IRQ thread to fix hang","id":"CVE-2024-35971"},"packages":[],"prev":{"headline":"ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr","id":"CVE-2024-35969"},"products":["Linux"],"published":"2024-05-20","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A race condition in the Linux kernel's AF_UNIX socket handling can cause a deadlock, leading to a denial of service.","url":"https://insights.sbomify.com/CVE-2024-35970/"}