{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-72118 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-72118 is a vulnerability in Linux, published on 15 Aug 2026. 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-2026-72118 and fix it if it is affected.\n\nWhat it is: CVE-2026-72118 is a vulnerability in Linux, published on 15 Aug 2026. 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-2026-72118 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-2026-72118/ (Markdown: https://insights.sbomify.com/CVE-2026-72118/index.md)","id":"CVE-2026-72118","markdown":"https://insights.sbomify.com/CVE-2026-72118/index.md","name":"CVE-2026-72118","record":{"aliases":["BELL-CVE-2026-72118","DEBIAN-CVE-2026-72118","GHSA-5pqf-xwxg-479q","UBUNTU-CVE-2026-72118"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["data_read"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel CAN","requires_auth":"none","summary":"A race condition in the Linux kernel CAN BCM module allows concurrent CPUs to corrupt statistics, potentially exposing incorrect data via procfs.","user_interaction":"not_required","vuln_class":"race_condition"},"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\ncan: bcm: fix CAN frame rx/tx statistics\n\nKCSAN detected a data race within the bcm_rx_handler() when two CAN frames\nhave been simultaneously received and processed in a single rx op by two\ndifferent CPUs.\n\nUse atomic operations with (signed) long data types to access the\nstatistics in the hot path to fix the KCSAN complaint.\n\nAdditionally simplify the update and check of statistics overflow by\nusing the atomic operations in separate bcm_update_[rx|tx]_stats()\nfunctions. The rx variant runs under bcm_rx_update_lock to prevent\nraces when resetting the two rx counters; the tx variant runs under\nbcm_tx_lock and only needs to guard its own counter's overflow.\n\nAs the rx path resets its values already at LONG_MAX / 100, there is\nno conflict between the two locking domains (bcm_rx_update_lock vs.\nbcm_tx_lock) even for ops that use both paths.\n\nThe rx statistics update and the frames_filtered update in\nbcm_rx_changed() were previously performed in two separate\nbcm_rx_update_lock sections. For an rx op subscribed on all interfaces\n(ifindex == 0), bcm_rx_handler() can run concurrently on different\nCPUs, so a counter reset by one CPU between these two sections could\nleave frames_filtered larger than frames_abs on another CPU, producing\na bogus (even negative) reduction percentage in procfs. Update the\nstatistics in the same critical section as bcm_rx_changed() to close\nthis gap, which also removes the now unneeded extra lock/unlock pair\naround the traffic_flags calculation.","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":"can: bcm: fix CAN frame rx/tx statistics","id":"CVE-2026-72118","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"race_condition","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"can: bcm: extend bcm_tx_lock usage for data and timer updates","id":"CVE-2026-72119"},"packages":[],"prev":{"headline":"can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()","id":"CVE-2026-72117"},"products":["Linux"],"published":"2026-08-15","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-08-19","vendors":["Linux"]},"summary":"A race condition in the Linux kernel CAN BCM module allows concurrent CPUs to corrupt statistics, potentially exposing incorrect data via procfs.","url":"https://insights.sbomify.com/CVE-2026-72118/"}