{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-80876 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-80876 is a vulnerability in Linux, published on 4 Sep 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-80876 and fix it if it is affected.\n\nWhat it is: CVE-2026-80876 is a vulnerability in Linux, published on 4 Sep 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-80876 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-80876/ (Markdown: https://insights.sbomify.com/CVE-2026-80876/index.md)","id":"CVE-2026-80876","markdown":"https://insights.sbomify.com/CVE-2026-80876/index.md","name":"CVE-2026-80876","record":{"aliases":["BELL-CVE-2026-80876","DEBIAN-CVE-2026-80876","GHSA-f6hv-xhx3-9x64","UBUNTU-CVE-2026-80876"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["data_read"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"none","summary":"A flaw in the Linux kernel ring buffer causes incorrect length reporting for small events on specific architectures, potentially leading to information disclosure.","user_interaction":"not_required","vuln_class":"information_disclosure"},"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\nring-buffer: Fix event length with forced 8-byte alignment\n\nWhen RB_FORCE_8BYTE_ALIGNMENT is true, rb_calculate_event_length()\nreserves the space of event-\u003earray[0] for placing the data length and\nrb_update_event() stores the data length in event-\u003earray[0]\naccordingly. As a result the whole event length will add extra 4 bytes\nfor sizeof(event.array[0]) unconditionally.\n\nBut ring_buffer_event_length() only subtracts the\nsizeof(event-\u003earray[0]) for events larger than RB_MAX_SMALL_DATA +\nsizeof(event-\u003earray[0]). As a result, small events on architectures\nwith RB_FORCE_8BYTE_ALIGNMENT=true report a data length that is 4\nbytes larger than expected.\n\nTo fix it, add the RB_FORCE_8BYTE_ALIGNMENT as a condition to subtract\nthe size of that length field whenever RB_FORCE_8BYTE_ALIGNMENT is\ntrue.\n\nThis issue is observed in a riscv64 kernel with\nCONFIG_HAVE_64BIT_ALIGNED_ACCESS set to y, when we run ftrace selftest\ntrace_marker_raw.tc, we get the weird log: for cases where the id is\n1..100, the number of data field is 8*N, but once id exceeds 100, the\nnumber of data field becomes 8*N+4:\n # 1 buf: 58 00 00 00 80 5e d1 63 (number of data field is 8*1)\n ...\n # a buf: 58 ...                  (number of data field is 8*2)\n ...\n # 64 buf: 58 ...                 (number of data field is 8*13)\n # 65 buf: 58 ...                 (number of data field is 8*13+4)\n\nAfter applying this change, the number of data field keeps being 8*N+4\nconsistently.","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":"ring-buffer: Fix event length with forced 8-byte alignment","id":"CVE-2026-80876","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"information_disclosure","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"afs: Fix vllist leak","id":"CVE-2026-80877"},"packages":[],"prev":{"headline":"ipvs: use parsed transport offset in TCP state lookup","id":"CVE-2026-80875"},"products":["Linux"],"published":"2026-09-04","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-09-04","vendors":["Linux"]},"summary":"A flaw in the Linux kernel ring buffer causes incorrect length reporting for small events on specific architectures, potentially leading to information disclosure.","url":"https://insights.sbomify.com/CVE-2026-80876/"}