{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-89979 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-89979 is a high-severity vulnerability in Linux, published on 16 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-89979 and fix it if it is affected.\n\nWhat it is: CVE-2026-89979 is a high-severity vulnerability in Linux, published on 16 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-89979 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-89979/ (Markdown: https://insights.sbomify.com/CVE-2026-89979/index.md)","id":"CVE-2026-89979","markdown":"https://insights.sbomify.com/CVE-2026-89979/index.md","name":"CVE-2026-89979","record":{"aliases":["AZL-101397","BELL-CVE-2026-89979","DEBIAN-CVE-2026-89979","GHSA-r2rw-736q-8cv3","UBUNTU-CVE-2026-89979"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel ALSA","requires_auth":"low_privilege","summary":"A race condition in the Linux kernel ALSA PCM subsystem allows concurrent operations to cause state inconsistencies and potential system warnings or crashes.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"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\nALSA: pcm: Fix race between non-atomic ops and trigger-start\n\nWe protect the races of the concurrent state transitions between\natomic PCM ops, but the checks between the non-atomic ops (hw_params,\nhw_free and prepare) and the atomic ops aren't perfect; there is a\ncheck of the conflicting PCM state at the beginning of hw_params \u0026 co,\nbut the atomic PCM ops can be still issued during the non-atomic PCM\noperations.  An example such scenario is that a thread A re-issues the\nPREPARE or HW_PARAMS for the already prepared stream, while another\nthread B triggers the PCM start in the middle of the prepare\noperation.  Although this usually doesn't lead to much serious issues,\nit can give some inconsistency as reported by syzkaller (such as\nODEBUG warning).\n\nThere are various atomic PCM ops, and basically the only problem is\nthe PCM start as it operates from the PREPARED state.  Other trigger\ncommands (stop, etc) are for the running or the other special state,\nhence they are filtered as pre-condition.\n\nThis patch is for preventing the PCM trigger-start during the non-\natomic operations in order to address the problems above.\nFortunately, the hw_params, hw_free and prepare operations call\nsnd_pcm_buffer_access_lock(), and this can be used for checking the\nconcurrent operations at the PCM trigger -- which sets the\nruntime-\u003ebuffer_accessing to a negative (if possible), so the PCM\ntrigger just needs to check the runtime-\u003ebuffer_accessing value; if\nit's negative, it means the concurrent non-atomic PCM ops is running.","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":"ALSA: pcm: Fix race between non-atomic ops and trigger-start","id":"CVE-2026-89979","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":"ALSA: harmony: initialize locks before requesting IRQ","id":"CVE-2026-89980"},"packages":[],"prev":{"headline":"accel/amdxdna: return early from a zero-length flush","id":"CVE-2026-89978"},"products":["Linux"],"published":"2026-09-16","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A race condition in the Linux kernel ALSA PCM subsystem allows concurrent operations to cause state inconsistencies and potential system warnings or crashes.","url":"https://insights.sbomify.com/CVE-2026-89979/"}