{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-42103 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-42103 is a high-severity vulnerability in Linux kernel, published on 30 Jul 2024. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2024-42103 and fix it if it is affected.\n\nWhat it is: CVE-2024-42103 is a high-severity vulnerability in Linux kernel, published on 30 Jul 2024. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2024-42103 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-42103/ (Markdown: https://insights.sbomify.com/CVE-2024-42103/index.md)","id":"CVE-2024-42103","markdown":"https://insights.sbomify.com/CVE-2024-42103/index.md","name":"CVE-2024-42103","record":{"aliases":["BELL-CVE-2024-42103","DEBIAN-CVE-2024-42103","GHSA-qj52-rm77-v6ch","UBUNTU-CVE-2024-42103"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel's Btrfs filesystem can cause list corruption and a kernel panic, leading to 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":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix adding block group to a reclaim list and the unused list during reclaim\n\nThere is a potential parallel list adding for retrying in\nbtrfs_reclaim_bgs_work and adding to the unused list. Since the block\ngroup is removed from the reclaim list and it is on a relocation work,\nit can be added into the unused list in parallel. When that happens,\nadding it to the reclaim list will corrupt the list head and trigger\nlist corruption like below.\n\nFix it by taking fs_info-\u003eunused_bgs_lock.\n\n  [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104\n  [177.514][T2585409] list_del corruption. next-\u003eprev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0)\n  [177.529][T2585409] ------------[ cut here ]------------\n  [177.537][T2585409] kernel BUG at lib/list_debug.c:65!\n  [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\n  [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G        W          6.10.0-rc5-kts #1\n  [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022\n  [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs]\n  [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286\n  [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000\n  [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40\n  [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08\n  [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0\n  [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000\n  [177.687][T2585409] FS:  0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000\n  [177.700][T2585409] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0\n  [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000\n  [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400\n  [177.742][T2585409] PKRU: 55555554\n  [177.748][T2585409] Call Trace:\n  [177.753][T2585409]  \u003cTASK\u003e\n  [177.759][T2585409]  ? __die_body.cold+0x19/0x27\n  [177.766][T2585409]  ? die+0x2e/0x50\n  [177.772][T2585409]  ? do_trap+0x1ea/0x2d0\n  [177.779][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.788][T2585409]  ? do_error_trap+0xa3/0x160\n  [177.795][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.805][T2585409]  ? handle_invalid_op+0x2c/0x40\n  [177.812][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.820][T2585409]  ? exc_invalid_op+0x2d/0x40\n  [177.827][T2585409]  ? asm_exc_invalid_op+0x1a/0x20\n  [177.834][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72\n  [177.843][T2585409]  btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]\n\nThere is a similar retry_list code in btrfs_delete_unused_bgs(), but it is\nsafe, AFAICS. Since the block group was in the unused list, the used bytes\nshould be 0 when it was added to the unused list. Then, it checks\nblock_group-\u003e{used,reserved,pinned} are still 0 under the\nblock_group-\u003elock. So, they should be still eligible for the unused list,\nnot the reclaim list.\n\nThe reason it is safe there it's because because we're holding\nspace_info-\u003egroups_sem in write mode.\n\nThat means no other task can allocate from the block group, so while we\nare at deleted_unused_bgs() it's not possible for other tasks to\nallocate and deallocate extents from the block group, so it can't be\nadded to the unused list or the reclaim list by anyone else.\n\nThe bug can be reproduced by btrfs/166 after a few rounds. In practice\nthis can be hit when relocation cannot find more chunk space and ends\nwith ENOSPC.","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":"btrfs: fix adding block group to a reclaim list and the unused list during reclaim","id":"CVE-2024-42103","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":"nilfs2: add missing check for inode numbers on directory entries","id":"CVE-2024-42104"},"packages":[],"prev":{"headline":"Revert \"mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\"","id":"CVE-2024-42102"},"products":["Linux"],"published":"2024-07-30","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":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A race condition in the Linux kernel's Btrfs filesystem can cause list corruption and a kernel panic, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2024-42103/"}