{"schema_version":"2","view":"grouped","data":[{"id":56228,"cve_ids":["CVE-2026-99083"],"payload":{"kind":"advisory","title":"ksmbd: fix heap out-of-bounds write in krb5_authenticate()","summary":"In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix heap out-of-bounds write in krb5_authenticate() In krb5_authenticate(), out_len is calculated to determine available headroom in response_buf for the incoming Kerberos AP-REP token. However, when SMB2_SESSION_SETUP is processed as a non-first element of a compounded SMB2 request, the calculation omits work->next_smb2_rsp_hdr_off. This causes out_len to overstate remaining buffer headroom by the cumulative size of prior responses in the compound chain. Consequently, the length check in ksmbd_krb5_authenticate() (*out_len <= resp->spnego_blob_len) passes erroneously, allowing memcpy() to write the AP-REP blob past the end of response_buf into adjacent kernel heap memory. Fix this by subtracting work->next_smb2_rsp_hdr_off when computing out_len, ensuring it accurately reflects physical remaining buffer space.","evidence":"cve:CVE-2026-99083","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99083","aliases":["CVE-2026-99083"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - ksmbd_conn_handler_loop() receives the compound request over TCP/445, and __process_request() dispatches its non-first SMB2 SESSION_SETUP to smb2_sess_setup() and krb5_authenticate(). The SESSION_SETUP SecurityBuffer carries the Kerberos AP-REQ that produces the AP-REP copied by the patched path.\nAC:L - The same authenticated peer can create directory entries, request a sized QUERY_DIRECTORY response, and place SESSION_SETUP later in the compound, controlling next_smb2_rsp_hdr_off before supplying its valid AP-REQ; no race or external actor is required.\nPR:L - ksmbd_krb5_authenticate() checks KSMBD_USER_FLAG_OK before its length check and memcpy; ksmbd.mountd sets it only after krb5_rd_req() accepts the AP-REQ and usm_handle_login_request() recognizes the account. An ordinary valid Kerberos account suffices, but an unauthenticated peer cannot reach the write.\nUI:N - The peer opens the session, prepares the prior compound response, and sends the Kerberos SESSION_SETUP itself; no victim user must open, mount, or approve anything.\nS:U - ksmbd_krb5_authenticate() corrupts memory adjacent to the host kernel's response_buf allocation; this remains within the same kernel security authority and crosses no VM, IOMMU, or sandbox boundary.\nC:H - The AP-REP memcpy in ksmbd_krb5_authenticate() can overrun response_buf and corrupt adjacent heap objects; exploitable kernel heap corruption can be converted into a memory-read primitive exposing arbitrary kernel data.\nI:H - The memcpy writes resp->spnego_blob_len AP-REP bytes beyond response_buf into adjacent kernel heap memory, enabling corruption of object metadata or control data and potential kernel code execution.\nA:H - Writing the AP-REP beyond response_buf can corrupt adjacent allocations or allocator metadata and trigger KASAN, an oops, or a kernel panic; the authenticated SMB peer can repeat the compound request."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"59c6dcc5dd9dafe764ca0d40525933b2be69b059","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"80af1bde97d5a85ad6f2c40ca894ccc8fa75a27a","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"517404e157395d0f8da125ca956c566895dfcd06","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"4722d06b2907585074252061b1024a696c1cfc23","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"23a0be6a84a38ac169eeab49017934e8e27c65f0","versionType":"git"},{"status":"affected","version":"0","lessThan":"6.6.160","versionType":"semver"},{"status":"affected","version":"0","lessThan":"6.12.114","versionType":"semver"},{"status":"affected","version":"0","lessThan":"6.18.58","versionType":"semver"},{"status":"affected","version":"0","lessThan":"7.2.12","versionType":"semver"}],"programFiles":["fs/smb/server/smb2pdu.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.58","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.12","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/smb/server/smb2pdu.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:24.950Z","provider":"cve","references":["https://git.kernel.org/stable/c/59c6dcc5dd9dafe764ca0d40525933b2be69b059","https://git.kernel.org/stable/c/80af1bde97d5a85ad6f2c40ca894ccc8fa75a27a","https://git.kernel.org/stable/c/517404e157395d0f8da125ca956c566895dfcd06","https://git.kernel.org/stable/c/4722d06b2907585074252061b1024a696c1cfc23","https://git.kernel.org/stable/c/23a0be6a84a38ac169eeab49017934e8e27c65f0"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:24.950Z"}}},"related_cves":[{"value":"CVE-2026-99083","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ececcc86-4fee-4bae-8e71-4f9ff22ffa88","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99083","advisory_id":"ececcc86-4fee-4bae-8e71-4f9ff22ffa88","event_types":["advisory"],"published_at":"2026-10-25T16:10:54.145367+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:45:01.735+00:00","detail_url":"/advisories/advisory%3Aececcc86-4fee-4bae-8e71-4f9ff22ffa88","group":{"id":"advisory:ececcc86-4fee-4bae-8e71-4f9ff22ffa88","revision":1,"primary_event_id":55752,"change":"published","superseded_by":[],"changed":{"id":55752,"cve_ids":["CVE-2026-99083"],"payload":{"kind":"advisory","title":"ksmbd: fix heap out-of-bounds write in krb5_authenticate()","summary":"In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix heap out-of-bounds write in krb5_authenticate() In krb5_authenticate(), out_len is calculated to determine available headroom in response_buf for the incoming Kerberos AP-REP token. However, when SMB2_SESSION_SETUP is processed as a non-first element of a compounded SMB2 request, the calculation omits work->next_smb2_rsp_hdr_off. This causes out_len to overstate remaining buffer headroom by the cumulative size of prior responses in the compound chain. Consequently, the length check in ksmbd_krb5_authenticate() (*out_len <= resp->spnego_blob_len) passes erroneously, allowing memcpy() to write the AP-REP blob past the end of response_buf into adjacent kernel heap memory. Fix this by subtracting work->next_smb2_rsp_hdr_off when computing out_len, ensuring it accurately reflects physical remaining buffer space.","evidence":"cve:CVE-2026-99083","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99083","aliases":["CVE-2026-99083"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - ksmbd_conn_handler_loop() receives the compound request over TCP/445, and __process_request() dispatches its non-first SMB2 SESSION_SETUP to smb2_sess_setup() and krb5_authenticate(). The SESSION_SETUP SecurityBuffer carries the Kerberos AP-REQ that produces the AP-REP copied by the patched path.\nAC:L - The same authenticated peer can create directory entries, request a sized QUERY_DIRECTORY response, and place SESSION_SETUP later in the compound, controlling next_smb2_rsp_hdr_off before supplying its valid AP-REQ; no race or external actor is required.\nPR:L - ksmbd_krb5_authenticate() checks KSMBD_USER_FLAG_OK before its length check and memcpy; ksmbd.mountd sets it only after krb5_rd_req() accepts the AP-REQ and usm_handle_login_request() recognizes the account. An ordinary valid Kerberos account suffices, but an unauthenticated peer cannot reach the write.\nUI:N - The peer opens the session, prepares the prior compound response, and sends the Kerberos SESSION_SETUP itself; no victim user must open, mount, or approve anything.\nS:U - ksmbd_krb5_authenticate() corrupts memory adjacent to the host kernel's response_buf allocation; this remains within the same kernel security authority and crosses no VM, IOMMU, or sandbox boundary.\nC:H - The AP-REP memcpy in ksmbd_krb5_authenticate() can overrun response_buf and corrupt adjacent heap objects; exploitable kernel heap corruption can be converted into a memory-read primitive exposing arbitrary kernel data.\nI:H - The memcpy writes resp->spnego_blob_len AP-REP bytes beyond response_buf into adjacent kernel heap memory, enabling corruption of object metadata or control data and potential kernel code execution.\nA:H - Writing the AP-REP beyond response_buf can corrupt adjacent allocations or allocator metadata and trigger KASAN, an oops, or a kernel panic; the authenticated SMB peer can repeat the compound request."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"59c6dcc5dd9dafe764ca0d40525933b2be69b059","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"80af1bde97d5a85ad6f2c40ca894ccc8fa75a27a","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"517404e157395d0f8da125ca956c566895dfcd06","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"4722d06b2907585074252061b1024a696c1cfc23","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"23a0be6a84a38ac169eeab49017934e8e27c65f0","versionType":"git"},{"status":"affected","version":"0","lessThan":"6.6.160","versionType":"semver"},{"status":"affected","version":"0","lessThan":"6.12.114","versionType":"semver"},{"status":"affected","version":"0","lessThan":"6.18.58","versionType":"semver"},{"status":"affected","version":"0","lessThan":"7.2.12","versionType":"semver"}],"programFiles":["fs/smb/server/smb2pdu.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.58","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.12","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/smb/server/smb2pdu.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:24.950Z","provider":"cve","references":["https://git.kernel.org/stable/c/59c6dcc5dd9dafe764ca0d40525933b2be69b059","https://git.kernel.org/stable/c/80af1bde97d5a85ad6f2c40ca894ccc8fa75a27a","https://git.kernel.org/stable/c/517404e157395d0f8da125ca956c566895dfcd06","https://git.kernel.org/stable/c/4722d06b2907585074252061b1024a696c1cfc23","https://git.kernel.org/stable/c/23a0be6a84a38ac169eeab49017934e8e27c65f0"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:24.950Z"}}},"related_cves":[{"value":"CVE-2026-99083","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ececcc86-4fee-4bae-8e71-4f9ff22ffa88","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99083","advisory_id":"ececcc86-4fee-4bae-8e71-4f9ff22ffa88","event_types":["advisory"],"published_at":"2026-10-25T16:10:54.145367+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:45:01.735+00:00","detail_url":"/events/55752"},"members":[{"id":55752,"cve_ids":["CVE-2026-99083"],"payload":{"kind":"advisory","title":"ksmbd: fix heap out-of-bounds write in krb5_authenticate()","summary":"In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix heap out-of-bounds write in krb5_authenticate() In krb5_authenticate(), out_len is calculated to determine available headroom in response_buf for the incoming Kerberos AP-REP token. However, when SMB2_SESSION_SETUP is processed as a non-first element of a compounded SMB2 request, the calculation omits work->next_smb2_rsp_hdr_off. This causes out_len to overstate remaining buffer headroom by the cumulative size of prior responses in the compound chain. Consequently, the length check in ksmbd_krb5_authenticate() (*out_len <= resp->spnego_blob_len) passes erroneously, allowing memcpy() to write the AP-REP blob past the end of response_buf into adjacent kernel heap memory. Fix this by subtracting work->next_smb2_rsp_hdr_off when computing out_len, ensuring it accurately reflects physical remaining buffer space.","evidence":"cve:CVE-2026-99083","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99083","aliases":["CVE-2026-99083"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - ksmbd_conn_handler_loop() receives the compound request over TCP/445, and __process_request() dispatches its non-first SMB2 SESSION_SETUP to smb2_sess_setup() and krb5_authenticate(). The SESSION_SETUP SecurityBuffer carries the Kerberos AP-REQ that produces the AP-REP copied by the patched path.\nAC:L - The same authenticated peer can create directory entries, request a sized QUERY_DIRECTORY response, and place SESSION_SETUP later in the compound, controlling next_smb2_rsp_hdr_off before supplying its valid AP-REQ; no race or external actor is required.\nPR:L - ksmbd_krb5_authenticate() checks KSMBD_USER_FLAG_OK before its length check and memcpy; ksmbd.mountd sets it only after krb5_rd_req() accepts the AP-REQ and usm_handle_login_request() recognizes the account. An ordinary valid Kerberos account suffices, but an unauthenticated peer cannot reach the write.\nUI:N - The peer opens the session, prepares the prior compound response, and sends the Kerberos SESSION_SETUP itself; no victim user must open, mount, or approve anything.\nS:U - ksmbd_krb5_authenticate() corrupts memory adjacent to the host kernel's response_buf allocation; this remains within the same kernel security authority and crosses no VM, IOMMU, or sandbox boundary.\nC:H - The AP-REP memcpy in ksmbd_krb5_authenticate() can overrun response_buf and corrupt adjacent heap objects; exploitable kernel heap corruption can be converted into a memory-read primitive exposing arbitrary kernel data.\nI:H - The memcpy writes resp->spnego_blob_len AP-REP bytes beyond response_buf into adjacent kernel heap memory, enabling corruption of object metadata or control data and potential kernel code execution.\nA:H - Writing the AP-REP beyond response_buf can corrupt adjacent allocations or allocator metadata and trigger KASAN, an oops, or a kernel panic; the authenticated SMB peer can repeat the compound request."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"59c6dcc5dd9dafe764ca0d40525933b2be69b059","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"80af1bde97d5a85ad6f2c40ca894ccc8fa75a27a","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"517404e157395d0f8da125ca956c566895dfcd06","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"4722d06b2907585074252061b1024a696c1cfc23","versionType":"git"},{"status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","lessThan":"23a0be6a84a38ac169eeab49017934e8e27c65f0","versionType":"git"},{"status":"affected","version":"0","lessThan":"6.6.160","versionType":"semver"},{"status":"affected","version":"0","lessThan":"6.12.114","versionType":"semver"},{"status":"affected","version":"0","lessThan":"6.18.58","versionType":"semver"},{"status":"affected","version":"0","lessThan":"7.2.12","versionType":"semver"}],"programFiles":["fs/smb/server/smb2pdu.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.58","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.12","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/smb/server/smb2pdu.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:24.950Z","provider":"cve","references":["https://git.kernel.org/stable/c/59c6dcc5dd9dafe764ca0d40525933b2be69b059","https://git.kernel.org/stable/c/80af1bde97d5a85ad6f2c40ca894ccc8fa75a27a","https://git.kernel.org/stable/c/517404e157395d0f8da125ca956c566895dfcd06","https://git.kernel.org/stable/c/4722d06b2907585074252061b1024a696c1cfc23","https://git.kernel.org/stable/c/23a0be6a84a38ac169eeab49017934e8e27c65f0"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:24.950Z"}}},"related_cves":[{"value":"CVE-2026-99083","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ececcc86-4fee-4bae-8e71-4f9ff22ffa88","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99083","advisory_id":"ececcc86-4fee-4bae-8e71-4f9ff22ffa88","event_types":["advisory"],"published_at":"2026-10-25T16:10:54.145367+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:45:01.735+00:00","detail_url":"/events/55752"}]}},{"id":56227,"cve_ids":["CVE-2026-99082"],"payload":{"kind":"advisory","title":"KVM: x86: Use active memslots for the per-vCPU MMIO cache","summary":"In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd3fbc4 (\"kvm: x86: fix stale mmio cache bug\") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 (\"KVM: x86: add SMM to the MMU role, support SMRAM address space\") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address space","evidence":"cve:CVE-2026-99082","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99082","aliases":["CVE-2026-99082"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attacker drives guest memory accesses through KVM_RUN via kvm_vcpu_ioctl()->kvm_arch_vcpu_ioctl_run()->handle_ept_violation()/handle_ept_misconfig()->kvm_mmu_page_fault(), reaching the patched MMIO-cache helpers; no network protocol carries the input.\nAC:L - A malicious L1 can deterministically enter SMM, fault on an unmapped GFN to fill the cache, alter Q35 SMRAM mappings, execute RSM, and write the same GFN; this requires no race, and the complete sequence was reproduced with nested VMX/EPT.\nPR:L - The demonstrated escape needs kernel-level control of the L1 guest to manage SMM and EPT12, but that is tenant-granted guest privilege relative to host KVM; neither kvm_mmu_page_fault() nor vcpu_match_mmio_gen() requires host administrative capability.\nUI:N - The malicious L1 performs the SMM access, Q35 SMRAM reconfiguration, RSM, nested-EPT update, and final RAM write itself, without any action by a host user or administrator.\nS:C - The flaw originates in host KVM's per-vCPU MMIO cache, while stale shadow EPT translations permit the guest to access host kernel memory, crossing the guest-to-host virtualization boundary.\nC:H - Bypassing kvm_page_track_write() leaves EPT02 translations derived from old EPT12 contents; on affected Linux 6.1.74 this exact stale mapping was demonstrated to provide arbitrary reads of host physical and kernel memory.\nI:H - The same stale EPT02 translations were demonstrated to provide arbitrary host-memory writes and host-kernel code execution after emulator_write_emulated() incorrectly routed the tracked EPT12 write through KVM_EXIT_MMIO.\nA:H - Arbitrary host-kernel writes and code execution can crash the host and all co-resident VMs; independently, the invalid cache state reaches WARN_ON_ONCE() in kvm_mmu_write_protect_fault(), which panics hardened panic_on_warn hosts."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"a63f79d9da9468952396af73e1e53330845cf876","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"2566780c684c9c21241d409d790087c73070f312","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"e792a9ace39d2812a5b342a1987186c7bc653204","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"b3e6212dea2e4328a841ceb37f377583176dc735","versionType":"git"}],"programFiles":["arch/x86/kvm/x86.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.2"},{"status":"unaffected","version":"0","lessThan":"4.2","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.58","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.12","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/x86/kvm/x86.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:23.875Z","provider":"cve","references":["https://git.kernel.org/stable/c/a63f79d9da9468952396af73e1e53330845cf876","https://git.kernel.org/stable/c/7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd","https://git.kernel.org/stable/c/2566780c684c9c21241d409d790087c73070f312","https://git.kernel.org/stable/c/e792a9ace39d2812a5b342a1987186c7bc653204","https://git.kernel.org/stable/c/b3e6212dea2e4328a841ceb37f377583176dc735"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:23.875Z"}}},"related_cves":[{"value":"CVE-2026-99082","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:9f15ed1a-1387-4a29-bce3-5fbacc456e4b","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99082","advisory_id":"9f15ed1a-1387-4a29-bce3-5fbacc456e4b","event_types":["advisory"],"published_at":"2026-10-25T16:10:53.510464+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:45:00.798+00:00","detail_url":"/advisories/advisory%3A9f15ed1a-1387-4a29-bce3-5fbacc456e4b","group":{"id":"advisory:9f15ed1a-1387-4a29-bce3-5fbacc456e4b","revision":1,"primary_event_id":55751,"change":"published","superseded_by":[],"changed":{"id":55751,"cve_ids":["CVE-2026-99082"],"payload":{"kind":"advisory","title":"KVM: x86: Use active memslots for the per-vCPU MMIO cache","summary":"In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd3fbc4 (\"kvm: x86: fix stale mmio cache bug\") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 (\"KVM: x86: add SMM to the MMU role, support SMRAM address space\") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address space","evidence":"cve:CVE-2026-99082","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99082","aliases":["CVE-2026-99082"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attacker drives guest memory accesses through KVM_RUN via kvm_vcpu_ioctl()->kvm_arch_vcpu_ioctl_run()->handle_ept_violation()/handle_ept_misconfig()->kvm_mmu_page_fault(), reaching the patched MMIO-cache helpers; no network protocol carries the input.\nAC:L - A malicious L1 can deterministically enter SMM, fault on an unmapped GFN to fill the cache, alter Q35 SMRAM mappings, execute RSM, and write the same GFN; this requires no race, and the complete sequence was reproduced with nested VMX/EPT.\nPR:L - The demonstrated escape needs kernel-level control of the L1 guest to manage SMM and EPT12, but that is tenant-granted guest privilege relative to host KVM; neither kvm_mmu_page_fault() nor vcpu_match_mmio_gen() requires host administrative capability.\nUI:N - The malicious L1 performs the SMM access, Q35 SMRAM reconfiguration, RSM, nested-EPT update, and final RAM write itself, without any action by a host user or administrator.\nS:C - The flaw originates in host KVM's per-vCPU MMIO cache, while stale shadow EPT translations permit the guest to access host kernel memory, crossing the guest-to-host virtualization boundary.\nC:H - Bypassing kvm_page_track_write() leaves EPT02 translations derived from old EPT12 contents; on affected Linux 6.1.74 this exact stale mapping was demonstrated to provide arbitrary reads of host physical and kernel memory.\nI:H - The same stale EPT02 translations were demonstrated to provide arbitrary host-memory writes and host-kernel code execution after emulator_write_emulated() incorrectly routed the tracked EPT12 write through KVM_EXIT_MMIO.\nA:H - Arbitrary host-kernel writes and code execution can crash the host and all co-resident VMs; independently, the invalid cache state reaches WARN_ON_ONCE() in kvm_mmu_write_protect_fault(), which panics hardened panic_on_warn hosts."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"a63f79d9da9468952396af73e1e53330845cf876","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"2566780c684c9c21241d409d790087c73070f312","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"e792a9ace39d2812a5b342a1987186c7bc653204","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"b3e6212dea2e4328a841ceb37f377583176dc735","versionType":"git"}],"programFiles":["arch/x86/kvm/x86.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.2"},{"status":"unaffected","version":"0","lessThan":"4.2","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.58","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.12","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/x86/kvm/x86.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:23.875Z","provider":"cve","references":["https://git.kernel.org/stable/c/a63f79d9da9468952396af73e1e53330845cf876","https://git.kernel.org/stable/c/7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd","https://git.kernel.org/stable/c/2566780c684c9c21241d409d790087c73070f312","https://git.kernel.org/stable/c/e792a9ace39d2812a5b342a1987186c7bc653204","https://git.kernel.org/stable/c/b3e6212dea2e4328a841ceb37f377583176dc735"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:23.875Z"}}},"related_cves":[{"value":"CVE-2026-99082","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:9f15ed1a-1387-4a29-bce3-5fbacc456e4b","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99082","advisory_id":"9f15ed1a-1387-4a29-bce3-5fbacc456e4b","event_types":["advisory"],"published_at":"2026-10-25T16:10:53.510464+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:45:00.798+00:00","detail_url":"/events/55751"},"members":[{"id":55751,"cve_ids":["CVE-2026-99082"],"payload":{"kind":"advisory","title":"KVM: x86: Use active memslots for the per-vCPU MMIO cache","summary":"In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use active memslots for the per-vCPU MMIO cache KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd3fbc4 (\"kvm: x86: fix stale mmio cache bug\") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e23965 (\"KVM: x86: add SMM to the MMU role, support SMRAM address space\") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address space","evidence":"cve:CVE-2026-99082","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99082","aliases":["CVE-2026-99082"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attacker drives guest memory accesses through KVM_RUN via kvm_vcpu_ioctl()->kvm_arch_vcpu_ioctl_run()->handle_ept_violation()/handle_ept_misconfig()->kvm_mmu_page_fault(), reaching the patched MMIO-cache helpers; no network protocol carries the input.\nAC:L - A malicious L1 can deterministically enter SMM, fault on an unmapped GFN to fill the cache, alter Q35 SMRAM mappings, execute RSM, and write the same GFN; this requires no race, and the complete sequence was reproduced with nested VMX/EPT.\nPR:L - The demonstrated escape needs kernel-level control of the L1 guest to manage SMM and EPT12, but that is tenant-granted guest privilege relative to host KVM; neither kvm_mmu_page_fault() nor vcpu_match_mmio_gen() requires host administrative capability.\nUI:N - The malicious L1 performs the SMM access, Q35 SMRAM reconfiguration, RSM, nested-EPT update, and final RAM write itself, without any action by a host user or administrator.\nS:C - The flaw originates in host KVM's per-vCPU MMIO cache, while stale shadow EPT translations permit the guest to access host kernel memory, crossing the guest-to-host virtualization boundary.\nC:H - Bypassing kvm_page_track_write() leaves EPT02 translations derived from old EPT12 contents; on affected Linux 6.1.74 this exact stale mapping was demonstrated to provide arbitrary reads of host physical and kernel memory.\nI:H - The same stale EPT02 translations were demonstrated to provide arbitrary host-memory writes and host-kernel code execution after emulator_write_emulated() incorrectly routed the tracked EPT12 write through KVM_EXIT_MMIO.\nA:H - Arbitrary host-kernel writes and code execution can crash the host and all co-resident VMs; independently, the invalid cache state reaches WARN_ON_ONCE() in kvm_mmu_write_protect_fault(), which panics hardened panic_on_warn hosts."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"a63f79d9da9468952396af73e1e53330845cf876","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"2566780c684c9c21241d409d790087c73070f312","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"e792a9ace39d2812a5b342a1987186c7bc653204","versionType":"git"},{"status":"affected","version":"699023e239658e62da6f42f47d31b54788521ec1","lessThan":"b3e6212dea2e4328a841ceb37f377583176dc735","versionType":"git"}],"programFiles":["arch/x86/kvm/x86.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.2"},{"status":"unaffected","version":"0","lessThan":"4.2","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.58","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.12","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/x86/kvm/x86.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:23.875Z","provider":"cve","references":["https://git.kernel.org/stable/c/a63f79d9da9468952396af73e1e53330845cf876","https://git.kernel.org/stable/c/7fd4e64f4bbc8c35ae8f0d2a1fb5b77a76d5b4fd","https://git.kernel.org/stable/c/2566780c684c9c21241d409d790087c73070f312","https://git.kernel.org/stable/c/e792a9ace39d2812a5b342a1987186c7bc653204","https://git.kernel.org/stable/c/b3e6212dea2e4328a841ceb37f377583176dc735"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:23.875Z"}}},"related_cves":[{"value":"CVE-2026-99082","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:9f15ed1a-1387-4a29-bce3-5fbacc456e4b","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99082","advisory_id":"9f15ed1a-1387-4a29-bce3-5fbacc456e4b","event_types":["advisory"],"published_at":"2026-10-25T16:10:53.510464+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:45:00.798+00:00","detail_url":"/events/55751"}]}},{"id":56226,"cve_ids":["CVE-2026-99079"],"payload":{"kind":"advisory","title":"net/mlx5e: Prevent stale XSK buffer release on refill retry","summary":"In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK buffer release on refill retry When an XDP redirect to an AF_XDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer. The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice. Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers. The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events, with no ownership or data errors.","evidence":"cve:CVE-2026-99079","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"critical","structured":{"id":"CVE-2026-99079","aliases":["CVE-2026-99079"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":9.8,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - UDP datagrams reaching mlx5 drive mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq()/XDP redirect, then mlx5e_napi_xsk_post() -> mlx5e_post_rx_wqes() -> patched mlx5e_xsk_free_rx_wqe(); sustained routable traffic fills the XSK RX ring and triggers stale release.\nAC:L - A sender can sustain small-packet traffic until __xsk_rcv_zc() reports RX-ring-full and mlx5e_xsk_alloc_rx_wqes_batched() refills only part of the missing WQEs; retries are deterministic and require no uncontrolled race or memory layout.\nPR:N - The NIC-CQE/NAPI receive path contains no capability or authentication check; xsk_create()'s CAP_NET_RAW check applies to victim-side AF_XDP provisioning, while the remote UDP sender needs no privileges.\nUI:N - Once the zero-copy XSK pool and XDP redirect are active, xsk_rcv_zc() failure, mlx5e_napi_xsk_post(), and refill retries occur automatically as packets arrive, without further victim action.\nS:U - mlx5e_xsk_free_rx_wqe() corrupts the host kernel's xsk_buff_pool and mlx5 receive state without crossing a VM, IOMMU, or other security-authority boundary.\nC:H - Duplicate xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls invoke unbounded xp_release(); in unaligned-UMEM mode, free_heads_cnt can write kernel pointers past the flexible free_heads[] array, yielding heap corruption exploitable for arbitrary disclosure.\nI:H - The duplicate WQEs can make xp_release() write beyond free_heads[], while xp_get_xskb() later trusts pointers popped through the corrupted count; this supplies out-of-bounds and corrupted-pointer write primitives capable of control-flow hijacking.\nA:H - The free_heads[] overflow or a bogus xskb consumed by xp_get_xskb() can oops or panic; additionally, the dma_dev_need_sync refill path can store NULL on allocation failure and have the stale retry pass it to xsk_buff_free()."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"32bbb870078d467479965c21bbc4960c57eea208","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"34d1db2b18e1c1d189e34dd51923e031815f88e3","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"639522e5056cade578a324acfa993ec6c9f7f5dc","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"655f47477054d19de3b138840be229a1a4490d0c","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"e01620844c5c88b6fcf819d171df8e3976a0e76f","versionType":"git"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en_rx.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.4"},{"status":"unaffected","version":"0","lessThan":"6.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en_rx.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:21.247Z","provider":"cve","references":["https://git.kernel.org/stable/c/32bbb870078d467479965c21bbc4960c57eea208","https://git.kernel.org/stable/c/34d1db2b18e1c1d189e34dd51923e031815f88e3","https://git.kernel.org/stable/c/639522e5056cade578a324acfa993ec6c9f7f5dc","https://git.kernel.org/stable/c/655f47477054d19de3b138840be229a1a4490d0c","https://git.kernel.org/stable/c/e01620844c5c88b6fcf819d171df8e3976a0e76f"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:21.247Z"}}},"related_cves":[{"value":"CVE-2026-99079","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:5002013d-532c-453d-aee9-d2fd13548bfc","priority":{"reasons":["publisher_severity"],"severity":"critical","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"critical"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99079","advisory_id":"5002013d-532c-453d-aee9-d2fd13548bfc","event_types":["advisory"],"published_at":"2026-10-25T16:10:52.846855+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:26.458+00:00","detail_url":"/advisories/advisory%3A5002013d-532c-453d-aee9-d2fd13548bfc","group":{"id":"advisory:5002013d-532c-453d-aee9-d2fd13548bfc","revision":1,"primary_event_id":55750,"change":"published","superseded_by":[],"changed":{"id":55750,"cve_ids":["CVE-2026-99079"],"payload":{"kind":"advisory","title":"net/mlx5e: Prevent stale XSK buffer release on refill retry","summary":"In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK buffer release on refill retry When an XDP redirect to an AF_XDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer. The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice. Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers. The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events, with no ownership or data errors.","evidence":"cve:CVE-2026-99079","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"critical","structured":{"id":"CVE-2026-99079","aliases":["CVE-2026-99079"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":9.8,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - UDP datagrams reaching mlx5 drive mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq()/XDP redirect, then mlx5e_napi_xsk_post() -> mlx5e_post_rx_wqes() -> patched mlx5e_xsk_free_rx_wqe(); sustained routable traffic fills the XSK RX ring and triggers stale release.\nAC:L - A sender can sustain small-packet traffic until __xsk_rcv_zc() reports RX-ring-full and mlx5e_xsk_alloc_rx_wqes_batched() refills only part of the missing WQEs; retries are deterministic and require no uncontrolled race or memory layout.\nPR:N - The NIC-CQE/NAPI receive path contains no capability or authentication check; xsk_create()'s CAP_NET_RAW check applies to victim-side AF_XDP provisioning, while the remote UDP sender needs no privileges.\nUI:N - Once the zero-copy XSK pool and XDP redirect are active, xsk_rcv_zc() failure, mlx5e_napi_xsk_post(), and refill retries occur automatically as packets arrive, without further victim action.\nS:U - mlx5e_xsk_free_rx_wqe() corrupts the host kernel's xsk_buff_pool and mlx5 receive state without crossing a VM, IOMMU, or other security-authority boundary.\nC:H - Duplicate xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls invoke unbounded xp_release(); in unaligned-UMEM mode, free_heads_cnt can write kernel pointers past the flexible free_heads[] array, yielding heap corruption exploitable for arbitrary disclosure.\nI:H - The duplicate WQEs can make xp_release() write beyond free_heads[], while xp_get_xskb() later trusts pointers popped through the corrupted count; this supplies out-of-bounds and corrupted-pointer write primitives capable of control-flow hijacking.\nA:H - The free_heads[] overflow or a bogus xskb consumed by xp_get_xskb() can oops or panic; additionally, the dma_dev_need_sync refill path can store NULL on allocation failure and have the stale retry pass it to xsk_buff_free()."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"32bbb870078d467479965c21bbc4960c57eea208","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"34d1db2b18e1c1d189e34dd51923e031815f88e3","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"639522e5056cade578a324acfa993ec6c9f7f5dc","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"655f47477054d19de3b138840be229a1a4490d0c","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"e01620844c5c88b6fcf819d171df8e3976a0e76f","versionType":"git"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en_rx.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.4"},{"status":"unaffected","version":"0","lessThan":"6.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en_rx.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:21.247Z","provider":"cve","references":["https://git.kernel.org/stable/c/32bbb870078d467479965c21bbc4960c57eea208","https://git.kernel.org/stable/c/34d1db2b18e1c1d189e34dd51923e031815f88e3","https://git.kernel.org/stable/c/639522e5056cade578a324acfa993ec6c9f7f5dc","https://git.kernel.org/stable/c/655f47477054d19de3b138840be229a1a4490d0c","https://git.kernel.org/stable/c/e01620844c5c88b6fcf819d171df8e3976a0e76f"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:21.247Z"}}},"related_cves":[{"value":"CVE-2026-99079","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:5002013d-532c-453d-aee9-d2fd13548bfc","priority":{"reasons":["publisher_severity"],"severity":"critical","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"critical"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99079","advisory_id":"5002013d-532c-453d-aee9-d2fd13548bfc","event_types":["advisory"],"published_at":"2026-10-25T16:10:52.846855+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:26.458+00:00","detail_url":"/events/55750"},"members":[{"id":55750,"cve_ids":["CVE-2026-99079"],"payload":{"kind":"advisory","title":"net/mlx5e: Prevent stale XSK buffer release on refill retry","summary":"In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK buffer release on refill retry When an XDP redirect to an AF_XDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer. The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice. Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers. The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events, with no ownership or data errors.","evidence":"cve:CVE-2026-99079","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"critical","structured":{"id":"CVE-2026-99079","aliases":["CVE-2026-99079"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":9.8,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - UDP datagrams reaching mlx5 drive mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq()/XDP redirect, then mlx5e_napi_xsk_post() -> mlx5e_post_rx_wqes() -> patched mlx5e_xsk_free_rx_wqe(); sustained routable traffic fills the XSK RX ring and triggers stale release.\nAC:L - A sender can sustain small-packet traffic until __xsk_rcv_zc() reports RX-ring-full and mlx5e_xsk_alloc_rx_wqes_batched() refills only part of the missing WQEs; retries are deterministic and require no uncontrolled race or memory layout.\nPR:N - The NIC-CQE/NAPI receive path contains no capability or authentication check; xsk_create()'s CAP_NET_RAW check applies to victim-side AF_XDP provisioning, while the remote UDP sender needs no privileges.\nUI:N - Once the zero-copy XSK pool and XDP redirect are active, xsk_rcv_zc() failure, mlx5e_napi_xsk_post(), and refill retries occur automatically as packets arrive, without further victim action.\nS:U - mlx5e_xsk_free_rx_wqe() corrupts the host kernel's xsk_buff_pool and mlx5 receive state without crossing a VM, IOMMU, or other security-authority boundary.\nC:H - Duplicate xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls invoke unbounded xp_release(); in unaligned-UMEM mode, free_heads_cnt can write kernel pointers past the flexible free_heads[] array, yielding heap corruption exploitable for arbitrary disclosure.\nI:H - The duplicate WQEs can make xp_release() write beyond free_heads[], while xp_get_xskb() later trusts pointers popped through the corrupted count; this supplies out-of-bounds and corrupted-pointer write primitives capable of control-flow hijacking.\nA:H - The free_heads[] overflow or a bogus xskb consumed by xp_get_xskb() can oops or panic; additionally, the dma_dev_need_sync refill path can store NULL on allocation failure and have the stale retry pass it to xsk_buff_free()."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"32bbb870078d467479965c21bbc4960c57eea208","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"34d1db2b18e1c1d189e34dd51923e031815f88e3","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"639522e5056cade578a324acfa993ec6c9f7f5dc","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"655f47477054d19de3b138840be229a1a4490d0c","versionType":"git"},{"status":"affected","version":"3f93f82988bc6b4104314bf9aa485d47fbb7e241","lessThan":"e01620844c5c88b6fcf819d171df8e3976a0e76f","versionType":"git"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en_rx.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.4"},{"status":"unaffected","version":"0","lessThan":"6.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en_rx.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:21.247Z","provider":"cve","references":["https://git.kernel.org/stable/c/32bbb870078d467479965c21bbc4960c57eea208","https://git.kernel.org/stable/c/34d1db2b18e1c1d189e34dd51923e031815f88e3","https://git.kernel.org/stable/c/639522e5056cade578a324acfa993ec6c9f7f5dc","https://git.kernel.org/stable/c/655f47477054d19de3b138840be229a1a4490d0c","https://git.kernel.org/stable/c/e01620844c5c88b6fcf819d171df8e3976a0e76f"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:21.247Z"}}},"related_cves":[{"value":"CVE-2026-99079","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:5002013d-532c-453d-aee9-d2fd13548bfc","priority":{"reasons":["publisher_severity"],"severity":"critical","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"critical"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99079","advisory_id":"5002013d-532c-453d-aee9-d2fd13548bfc","event_types":["advisory"],"published_at":"2026-10-25T16:10:52.846855+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:26.458+00:00","detail_url":"/events/55750"}]}},{"id":56225,"cve_ids":["CVE-2026-99081"],"payload":{"kind":"advisory","title":"bnxt_en: fix DMA mapping length for padded small packets","summary":"In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix DMA mapping length for padded small packets Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: if (length < BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length: txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 byt","evidence":"cve:CVE-2026-99081","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99081","aliases":["CVE-2026-99081"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A minimal IPv4 ICMP Echo Request follows bnxt_poll→bnxt_rx_pkt→icmp_rcv→icmp_echo; icmp_reply builds a 42-byte reply that reaches the patched bnxt_start_xmit through ip_finish_output2→dev_queue_xmit, including vlan_dev_hard_start_xmit on the reported VLAN setup.\nAC:L - A request burst keeps the TX ring nonempty, bypassing the push fast path and repeatedly exercising the 42-to-52-byte mismatch; repeated skb allocations provide the documented 4-KiB boundary placement without a race, second actor, or hardware failure.\nPR:N - icmp_rcv and icmp_echo process the Echo Request and invoke icmp_reply without socket credentials, capability checks, or authentication, so the remote sender needs no account or privileges.\nUI:N - Receipt of the ICMP Echo Request automatically constructs and transmits the short reply through bnxt_start_xmit; no victim must open a file, run a command, or otherwise act.\nS:U - bnxt_start_xmit misprograms the host NIC's TX DMA length, but the IOMMU rejects the overrun rather than being bypassed; no guest, sandbox, or other security authority is crossed.\nC:N - skb_pad zero-fills the intended ten padding bytes, while the demonstrated access reaches an unmapped IOVA page and faults; the code provides no path that returns host memory to the routed ICMP peer.\nI:N - The erroneous operation is a DMA_TO_DEVICE read of up to ten bytes beyond the mapping; it neither authorizes a NIC write into host memory nor modifies kernel data.\nA:H - The 52-byte descriptor read from a 42-byte mapping causes the documented IOMMU fault and NETDEV WATCHDOG TX-queue timeout; bnxt_tx_timeout then schedules bnxt_reset_task to close and reopen the NIC, and repeated requests can continually disrupt all interface traffic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"cf8530a25ae92c4493e2f22981ecb46f0b66f4c8","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"2956aca14dd2977cd08bd2ccafae3beb8b84b268","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"fbd977e513971ccb4f0762a7f59eac500e474f89","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"5213f65a9667d3dd85db2e6df8f2e0516290db34","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"a51d233ccd4889aadb71dace863525cc2b00271e","versionType":"git"}],"programFiles":["drivers/net/ethernet/broadcom/bnxt/bnxt.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.4"},{"status":"unaffected","version":"0","lessThan":"4.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/broadcom/bnxt/bnxt.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:22.790Z","provider":"cve","references":["https://git.kernel.org/stable/c/cf8530a25ae92c4493e2f22981ecb46f0b66f4c8","https://git.kernel.org/stable/c/2956aca14dd2977cd08bd2ccafae3beb8b84b268","https://git.kernel.org/stable/c/fbd977e513971ccb4f0762a7f59eac500e474f89","https://git.kernel.org/stable/c/5213f65a9667d3dd85db2e6df8f2e0516290db34","https://git.kernel.org/stable/c/a51d233ccd4889aadb71dace863525cc2b00271e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:22.790Z"}}},"related_cves":[{"value":"CVE-2026-99081","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d42e42ef-cad9-40dd-828c-e1e5a2533fe1","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99081","advisory_id":"d42e42ef-cad9-40dd-828c-e1e5a2533fe1","event_types":["advisory"],"published_at":"2026-10-25T16:10:52.17115+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:28.347+00:00","detail_url":"/advisories/advisory%3Ad42e42ef-cad9-40dd-828c-e1e5a2533fe1","group":{"id":"advisory:d42e42ef-cad9-40dd-828c-e1e5a2533fe1","revision":1,"primary_event_id":55749,"change":"published","superseded_by":[],"changed":{"id":55749,"cve_ids":["CVE-2026-99081"],"payload":{"kind":"advisory","title":"bnxt_en: fix DMA mapping length for padded small packets","summary":"In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix DMA mapping length for padded small packets Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: if (length < BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length: txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 byt","evidence":"cve:CVE-2026-99081","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99081","aliases":["CVE-2026-99081"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A minimal IPv4 ICMP Echo Request follows bnxt_poll→bnxt_rx_pkt→icmp_rcv→icmp_echo; icmp_reply builds a 42-byte reply that reaches the patched bnxt_start_xmit through ip_finish_output2→dev_queue_xmit, including vlan_dev_hard_start_xmit on the reported VLAN setup.\nAC:L - A request burst keeps the TX ring nonempty, bypassing the push fast path and repeatedly exercising the 42-to-52-byte mismatch; repeated skb allocations provide the documented 4-KiB boundary placement without a race, second actor, or hardware failure.\nPR:N - icmp_rcv and icmp_echo process the Echo Request and invoke icmp_reply without socket credentials, capability checks, or authentication, so the remote sender needs no account or privileges.\nUI:N - Receipt of the ICMP Echo Request automatically constructs and transmits the short reply through bnxt_start_xmit; no victim must open a file, run a command, or otherwise act.\nS:U - bnxt_start_xmit misprograms the host NIC's TX DMA length, but the IOMMU rejects the overrun rather than being bypassed; no guest, sandbox, or other security authority is crossed.\nC:N - skb_pad zero-fills the intended ten padding bytes, while the demonstrated access reaches an unmapped IOVA page and faults; the code provides no path that returns host memory to the routed ICMP peer.\nI:N - The erroneous operation is a DMA_TO_DEVICE read of up to ten bytes beyond the mapping; it neither authorizes a NIC write into host memory nor modifies kernel data.\nA:H - The 52-byte descriptor read from a 42-byte mapping causes the documented IOMMU fault and NETDEV WATCHDOG TX-queue timeout; bnxt_tx_timeout then schedules bnxt_reset_task to close and reopen the NIC, and repeated requests can continually disrupt all interface traffic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"cf8530a25ae92c4493e2f22981ecb46f0b66f4c8","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"2956aca14dd2977cd08bd2ccafae3beb8b84b268","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"fbd977e513971ccb4f0762a7f59eac500e474f89","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"5213f65a9667d3dd85db2e6df8f2e0516290db34","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"a51d233ccd4889aadb71dace863525cc2b00271e","versionType":"git"}],"programFiles":["drivers/net/ethernet/broadcom/bnxt/bnxt.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.4"},{"status":"unaffected","version":"0","lessThan":"4.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/broadcom/bnxt/bnxt.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:22.790Z","provider":"cve","references":["https://git.kernel.org/stable/c/cf8530a25ae92c4493e2f22981ecb46f0b66f4c8","https://git.kernel.org/stable/c/2956aca14dd2977cd08bd2ccafae3beb8b84b268","https://git.kernel.org/stable/c/fbd977e513971ccb4f0762a7f59eac500e474f89","https://git.kernel.org/stable/c/5213f65a9667d3dd85db2e6df8f2e0516290db34","https://git.kernel.org/stable/c/a51d233ccd4889aadb71dace863525cc2b00271e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:22.790Z"}}},"related_cves":[{"value":"CVE-2026-99081","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d42e42ef-cad9-40dd-828c-e1e5a2533fe1","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99081","advisory_id":"d42e42ef-cad9-40dd-828c-e1e5a2533fe1","event_types":["advisory"],"published_at":"2026-10-25T16:10:52.17115+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:28.347+00:00","detail_url":"/events/55749"},"members":[{"id":55749,"cve_ids":["CVE-2026-99081"],"payload":{"kind":"advisory","title":"bnxt_en: fix DMA mapping length for padded small packets","summary":"In the Linux kernel, the following vulnerability has been resolved: bnxt_en: fix DMA mapping length for padded small packets Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412 NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces: DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000 [fault reason 0x06] PTE Read access is not set bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001 ... NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out The fault address (0xfc499000) is on an exact 4KB page boundary, pointing to a DMA read buffer overrun. In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes), such as 42-byte untagged ARP frames, are padded: if (length < BNXT_MIN_PKT_SIZE) { pad = BNXT_MIN_PKT_SIZE - length; if (skb_pad(skb, pad)) goto tx_kick_pending; length = BNXT_MIN_PKT_SIZE; } mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE); ... dma_unmap_len_set(tx_buf, len, len); However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes) and is left unadjusted after padding. Consequently, dma_map_single() and dma_unmap_len_set() map and track only 42 bytes. Later, the hardware TX buffer descriptor is programmed with the padded length: txbd->tx_bd_len_flags_type = cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags | TX_BD_FLAGS_PACKET_END); The NIC DMA engine is thus instructed to read 52 bytes from a region where only 42 byt","evidence":"cve:CVE-2026-99081","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99081","aliases":["CVE-2026-99081"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A minimal IPv4 ICMP Echo Request follows bnxt_poll→bnxt_rx_pkt→icmp_rcv→icmp_echo; icmp_reply builds a 42-byte reply that reaches the patched bnxt_start_xmit through ip_finish_output2→dev_queue_xmit, including vlan_dev_hard_start_xmit on the reported VLAN setup.\nAC:L - A request burst keeps the TX ring nonempty, bypassing the push fast path and repeatedly exercising the 42-to-52-byte mismatch; repeated skb allocations provide the documented 4-KiB boundary placement without a race, second actor, or hardware failure.\nPR:N - icmp_rcv and icmp_echo process the Echo Request and invoke icmp_reply without socket credentials, capability checks, or authentication, so the remote sender needs no account or privileges.\nUI:N - Receipt of the ICMP Echo Request automatically constructs and transmits the short reply through bnxt_start_xmit; no victim must open a file, run a command, or otherwise act.\nS:U - bnxt_start_xmit misprograms the host NIC's TX DMA length, but the IOMMU rejects the overrun rather than being bypassed; no guest, sandbox, or other security authority is crossed.\nC:N - skb_pad zero-fills the intended ten padding bytes, while the demonstrated access reaches an unmapped IOVA page and faults; the code provides no path that returns host memory to the routed ICMP peer.\nI:N - The erroneous operation is a DMA_TO_DEVICE read of up to ten bytes beyond the mapping; it neither authorizes a NIC write into host memory nor modifies kernel data.\nA:H - The 52-byte descriptor read from a 42-byte mapping causes the documented IOMMU fault and NETDEV WATCHDOG TX-queue timeout; bnxt_tx_timeout then schedules bnxt_reset_task to close and reopen the NIC, and repeated requests can continually disrupt all interface traffic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"cf8530a25ae92c4493e2f22981ecb46f0b66f4c8","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"2956aca14dd2977cd08bd2ccafae3beb8b84b268","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"fbd977e513971ccb4f0762a7f59eac500e474f89","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"5213f65a9667d3dd85db2e6df8f2e0516290db34","versionType":"git"},{"status":"affected","version":"c0c050c58d840994ba842ad1c338a98e7c12b764","lessThan":"a51d233ccd4889aadb71dace863525cc2b00271e","versionType":"git"}],"programFiles":["drivers/net/ethernet/broadcom/bnxt/bnxt.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.4"},{"status":"unaffected","version":"0","lessThan":"4.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/broadcom/bnxt/bnxt.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:22.790Z","provider":"cve","references":["https://git.kernel.org/stable/c/cf8530a25ae92c4493e2f22981ecb46f0b66f4c8","https://git.kernel.org/stable/c/2956aca14dd2977cd08bd2ccafae3beb8b84b268","https://git.kernel.org/stable/c/fbd977e513971ccb4f0762a7f59eac500e474f89","https://git.kernel.org/stable/c/5213f65a9667d3dd85db2e6df8f2e0516290db34","https://git.kernel.org/stable/c/a51d233ccd4889aadb71dace863525cc2b00271e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:22.790Z"}}},"related_cves":[{"value":"CVE-2026-99081","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d42e42ef-cad9-40dd-828c-e1e5a2533fe1","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99081","advisory_id":"d42e42ef-cad9-40dd-828c-e1e5a2533fe1","event_types":["advisory"],"published_at":"2026-10-25T16:10:52.17115+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:28.347+00:00","detail_url":"/events/55749"}]}},{"id":56224,"cve_ids":["CVE-2026-99077"],"payload":{"kind":"advisory","title":"ipv4: udp: Create exceptions before socket matching","summary":"In the Linux kernel, the following vulnerability has been resolved: ipv4: udp: Create exceptions before socket matching Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket. Commit 6457378fe796 (\"ipv4: use siphash instead of Jenkins in fnhe_hashfun()\") and commit 67d6d681e15b (\"ipv4: make exception cache less predictible\") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4_update_pmtu() and ipv4_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe. Pass an oif of 0, in a similar fashion to icmp_err(). This is also the oif used by the socket path for sockets that are not bound to a device. Note that this does not allow attackers to crea","evidence":"cve:CVE-2026-99077","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99077","aliases":["CVE-2026-99077"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"},"scenarios":[{"lang":"en","value":"AV:N - A remote IPv4 ICMP Fragmentation Needed or Redirect message carries the attacker-controlled inner IPv4/UDP quote through ip_rcv(), icmp_rcv(), icmp_socket_deliver(), and udp_err(), where its guessed four-tuple is matched.\nAC:H - Exploiting a connected socket requires turning fnhe_hashfun() bucket occupancy and update_or_create_fnhe() eviction into an oracle while the UDP tuple remains live; keyed hashing, randomized bucket depth, cache noise, and the short DNS response window are conditions the attacker cannot fully determine, although the mitigations can be bypassed.\nPR:N - icmp_rcv() checks packet structure, checksum, and policy but has no authentication or capability gate; icmp_unreach() passes a valid Fragmentation Needed quote to udp_err() without verifying that its sender is an on-path router.\nUI:N - The attacker can induce a resolver's connected UDP socket with a DNS query and then send the ICMP probes and cache-verification traffic; no victim user action is required.\nS:U - The FNHE oracle in udp_err() compromises networking and application data governed by the same host security authority; it does not cross a VM, IOMMU, or sandbox boundary.\nC:H - The __udp4_lib_lookup() result controls whether ipv4_sk_update_pmtu() or ipv4_sk_redirect() leaves an observable FNHE, disclosing the complete ephemeral source port. On a recursive DNS resolver, removing that entropy enables cache poisoning and redirection of client traffic, permitting broad disclosure.\nI:H - After learning the port, the same attacker can forge UDP DNS replies and brute-force the remaining transaction ID; an accepted reply can poison the resolver cache and map chosen names to attacker-controlled addresses.\nA:N - The fixed defect is the match-dependent FNHE oracle, not memory corruption or a crash. update_or_create_fnhe() already accepts other minimally validated ICMP cases, and the fix deliberately preserves exception creation, so route-cache manipulation is not an availability impact removed by this patch."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4895c771c7f006b4b90f9d6b1d2210939ba57b38","lessThan":"be4fd05398f2b5e42029be70ee875fc749b8ce3a","versionType":"git"},{"status":"affected","version":"4895c771c7f006b4b90f9d6b1d2210939ba57b38","lessThan":"4c3499f79f8c7e8561266bcc220a18538cec0458","versionType":"git"}],"programFiles":["net/ipv4/udp.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.6"},{"status":"unaffected","version":"0","lessThan":"3.6","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/ipv4/udp.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:19.075Z","provider":"cve","references":["https://git.kernel.org/stable/c/be4fd05398f2b5e42029be70ee875fc749b8ce3a","https://git.kernel.org/stable/c/4c3499f79f8c7e8561266bcc220a18538cec0458"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:19.075Z"}}},"related_cves":[{"value":"CVE-2026-99077","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ea7305e8-5793-40c8-b975-c669294d4ef2","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99077","advisory_id":"ea7305e8-5793-40c8-b975-c669294d4ef2","event_types":["advisory"],"published_at":"2026-10-25T16:10:51.531283+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:22.773+00:00","detail_url":"/advisories/advisory%3Aea7305e8-5793-40c8-b975-c669294d4ef2","group":{"id":"advisory:ea7305e8-5793-40c8-b975-c669294d4ef2","revision":1,"primary_event_id":55748,"change":"published","superseded_by":[],"changed":{"id":55748,"cve_ids":["CVE-2026-99077"],"payload":{"kind":"advisory","title":"ipv4: udp: Create exceptions before socket matching","summary":"In the Linux kernel, the following vulnerability has been resolved: ipv4: udp: Create exceptions before socket matching Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket. Commit 6457378fe796 (\"ipv4: use siphash instead of Jenkins in fnhe_hashfun()\") and commit 67d6d681e15b (\"ipv4: make exception cache less predictible\") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4_update_pmtu() and ipv4_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe. Pass an oif of 0, in a similar fashion to icmp_err(). This is also the oif used by the socket path for sockets that are not bound to a device. Note that this does not allow attackers to crea","evidence":"cve:CVE-2026-99077","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99077","aliases":["CVE-2026-99077"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"},"scenarios":[{"lang":"en","value":"AV:N - A remote IPv4 ICMP Fragmentation Needed or Redirect message carries the attacker-controlled inner IPv4/UDP quote through ip_rcv(), icmp_rcv(), icmp_socket_deliver(), and udp_err(), where its guessed four-tuple is matched.\nAC:H - Exploiting a connected socket requires turning fnhe_hashfun() bucket occupancy and update_or_create_fnhe() eviction into an oracle while the UDP tuple remains live; keyed hashing, randomized bucket depth, cache noise, and the short DNS response window are conditions the attacker cannot fully determine, although the mitigations can be bypassed.\nPR:N - icmp_rcv() checks packet structure, checksum, and policy but has no authentication or capability gate; icmp_unreach() passes a valid Fragmentation Needed quote to udp_err() without verifying that its sender is an on-path router.\nUI:N - The attacker can induce a resolver's connected UDP socket with a DNS query and then send the ICMP probes and cache-verification traffic; no victim user action is required.\nS:U - The FNHE oracle in udp_err() compromises networking and application data governed by the same host security authority; it does not cross a VM, IOMMU, or sandbox boundary.\nC:H - The __udp4_lib_lookup() result controls whether ipv4_sk_update_pmtu() or ipv4_sk_redirect() leaves an observable FNHE, disclosing the complete ephemeral source port. On a recursive DNS resolver, removing that entropy enables cache poisoning and redirection of client traffic, permitting broad disclosure.\nI:H - After learning the port, the same attacker can forge UDP DNS replies and brute-force the remaining transaction ID; an accepted reply can poison the resolver cache and map chosen names to attacker-controlled addresses.\nA:N - The fixed defect is the match-dependent FNHE oracle, not memory corruption or a crash. update_or_create_fnhe() already accepts other minimally validated ICMP cases, and the fix deliberately preserves exception creation, so route-cache manipulation is not an availability impact removed by this patch."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4895c771c7f006b4b90f9d6b1d2210939ba57b38","lessThan":"be4fd05398f2b5e42029be70ee875fc749b8ce3a","versionType":"git"},{"status":"affected","version":"4895c771c7f006b4b90f9d6b1d2210939ba57b38","lessThan":"4c3499f79f8c7e8561266bcc220a18538cec0458","versionType":"git"}],"programFiles":["net/ipv4/udp.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.6"},{"status":"unaffected","version":"0","lessThan":"3.6","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/ipv4/udp.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:19.075Z","provider":"cve","references":["https://git.kernel.org/stable/c/be4fd05398f2b5e42029be70ee875fc749b8ce3a","https://git.kernel.org/stable/c/4c3499f79f8c7e8561266bcc220a18538cec0458"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:19.075Z"}}},"related_cves":[{"value":"CVE-2026-99077","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ea7305e8-5793-40c8-b975-c669294d4ef2","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99077","advisory_id":"ea7305e8-5793-40c8-b975-c669294d4ef2","event_types":["advisory"],"published_at":"2026-10-25T16:10:51.531283+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:22.773+00:00","detail_url":"/events/55748"},"members":[{"id":55748,"cve_ids":["CVE-2026-99077"],"payload":{"kind":"advisory","title":"ipv4: udp: Create exceptions before socket matching","summary":"In the Linux kernel, the following vulnerability has been resolved: ipv4: udp: Create exceptions before socket matching Currently, when ICMP Fragmentation Needed and Redirect Message packets are locally delivered and quote a UDP packet, a FIB nexthop exception (FNHE) is only created if the kernel can match the UDP packet to an existing socket. This behavior allows off-path attackers to conduct a side-channel attack on the FNHE cache in order to discover the ephemeral port used by a connected UDP socket. Commit 6457378fe796 (\"ipv4: use siphash instead of Jenkins in fnhe_hashfun()\") and commit 67d6d681e15b (\"ipv4: make exception cache less predictible\") tried to mitigate such attacks by making it harder for attackers to discover hash collisions in the FNHE cache and by randomizing the number of exceptions a hash bucket can hold, respectively. Unfortunately, both of the mitigations can be bypassed. Instead, mitigate such attacks by always creating a FNHE, even before trying to find a matching socket. Do that by calling ipv4_update_pmtu() and ipv4_redirect(), the helpers used when the quoted packet did not originate from a socket. This means that guesses (right or wrong) from an off-path attacker will always result in a FNHE being created or updated in the cache that the attacker can observe. Pass an oif of 0, in a similar fashion to icmp_err(). This is also the oif used by the socket path for sockets that are not bound to a device. Note that this does not allow attackers to crea","evidence":"cve:CVE-2026-99077","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99077","aliases":["CVE-2026-99077"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"},"scenarios":[{"lang":"en","value":"AV:N - A remote IPv4 ICMP Fragmentation Needed or Redirect message carries the attacker-controlled inner IPv4/UDP quote through ip_rcv(), icmp_rcv(), icmp_socket_deliver(), and udp_err(), where its guessed four-tuple is matched.\nAC:H - Exploiting a connected socket requires turning fnhe_hashfun() bucket occupancy and update_or_create_fnhe() eviction into an oracle while the UDP tuple remains live; keyed hashing, randomized bucket depth, cache noise, and the short DNS response window are conditions the attacker cannot fully determine, although the mitigations can be bypassed.\nPR:N - icmp_rcv() checks packet structure, checksum, and policy but has no authentication or capability gate; icmp_unreach() passes a valid Fragmentation Needed quote to udp_err() without verifying that its sender is an on-path router.\nUI:N - The attacker can induce a resolver's connected UDP socket with a DNS query and then send the ICMP probes and cache-verification traffic; no victim user action is required.\nS:U - The FNHE oracle in udp_err() compromises networking and application data governed by the same host security authority; it does not cross a VM, IOMMU, or sandbox boundary.\nC:H - The __udp4_lib_lookup() result controls whether ipv4_sk_update_pmtu() or ipv4_sk_redirect() leaves an observable FNHE, disclosing the complete ephemeral source port. On a recursive DNS resolver, removing that entropy enables cache poisoning and redirection of client traffic, permitting broad disclosure.\nI:H - After learning the port, the same attacker can forge UDP DNS replies and brute-force the remaining transaction ID; an accepted reply can poison the resolver cache and map chosen names to attacker-controlled addresses.\nA:N - The fixed defect is the match-dependent FNHE oracle, not memory corruption or a crash. update_or_create_fnhe() already accepts other minimally validated ICMP cases, and the fix deliberately preserves exception creation, so route-cache manipulation is not an availability impact removed by this patch."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4895c771c7f006b4b90f9d6b1d2210939ba57b38","lessThan":"be4fd05398f2b5e42029be70ee875fc749b8ce3a","versionType":"git"},{"status":"affected","version":"4895c771c7f006b4b90f9d6b1d2210939ba57b38","lessThan":"4c3499f79f8c7e8561266bcc220a18538cec0458","versionType":"git"}],"programFiles":["net/ipv4/udp.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.6"},{"status":"unaffected","version":"0","lessThan":"3.6","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/ipv4/udp.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:19.075Z","provider":"cve","references":["https://git.kernel.org/stable/c/be4fd05398f2b5e42029be70ee875fc749b8ce3a","https://git.kernel.org/stable/c/4c3499f79f8c7e8561266bcc220a18538cec0458"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:19.075Z"}}},"related_cves":[{"value":"CVE-2026-99077","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ea7305e8-5793-40c8-b975-c669294d4ef2","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99077","advisory_id":"ea7305e8-5793-40c8-b975-c669294d4ef2","event_types":["advisory"],"published_at":"2026-10-25T16:10:51.531283+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:22.773+00:00","detail_url":"/events/55748"}]}},{"id":56223,"cve_ids":["CVE-2026-99078"],"payload":{"kind":"advisory","title":"net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry","summary":"In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actual_wq_head is not advanced and a later NAPI poll retries the same WQE. mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On retry it can therefore call xsk_buff_free() again through stale pointers after the frames have returned to the XSK pool and been reallocated. Set all skip_release_bitmap bits in the common error path of mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path. Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AF_XDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings.","evidence":"cve:CVE-2026-99078","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"critical","structured":{"id":"CVE-2026-99078","aliases":["CVE-2026-99078"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":9.8,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - Routable IP packets received by mlx5 consume the AF_XDP striding RQ through mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq(), after which mlx5e_napi_xsk_post() -> mlx5e_post_rx_mpwqes() reaches patched mlx5e_xsk_alloc_rx_mpwqe(); packet pressure exhausts the RX/Fill rings and triggers the stale-buffer retry.\nAC:L - A sender can flood the XSK-bound RSS queue until XDP redirect and refill allocation fail, then continue traffic so NAPI retries the unchanged actual_wq_head; no uncontrolled race is needed for mlx5e_free_rx_mpwqe() to release the stale pointer.\nPR:N - The receive path beginning at mlx5e_completion_event() performs no authentication or capability check; xsk_create()'s CAP_NET_RAW requirement applies to victim-side AF_XDP provisioning, while the remote IP sender needs no privileges.\nUI:N - Once an mlx5 AF_XDP zero-copy pool and XDP program are running, packet receipt, mlx5e_napi_xsk_post(), and the refill retries occur automatically without further victim action.\nS:U - The corrupted xsk_buff_pool metadata and mlx5 receive state belong to the host kernel; the bug crosses no VM, IOMMU, or other security-authority boundary.\nC:H - In unaligned-UMEM mode, duplicate live xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls make xp_release() write kernel pointers past the pool's flexible free_heads[] array; this heap corruption can be leveraged to disclose arbitrary kernel memory.\nI:H - The same xp_release() overflow is an out-of-bounds kernel heap write; subsequent xp_get_xskb() trusts pointers popped from corrupted free_heads[] and initializes through them, supporting arbitrary writes or control-flow corruption.\nA:H - Overflowing free_heads[] or later dereferencing a bogus xskb in xp_get_xskb() can oops or panic; even without a crash, duplicate UMEM ownership can prevent mlx5e_xsk_alloc_rx_mpwqe() from restoring WQEs and stop the bound receive queue."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"f3a52e2ec2788a7f6b64137985c087188a54ad4f","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"d215d09606b0fcd18ad1eb532995782a21cea49d","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"867119b4b588037724b85839d534465f0334d9bd","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"3d73a1164a8c6b4461907a65cb6c022ea4fd39af","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"63811edf512584c946e5e96b100e9e280703bbb5","versionType":"git"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.4"},{"status":"unaffected","version":"0","lessThan":"6.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:20.145Z","provider":"cve","references":["https://git.kernel.org/stable/c/f3a52e2ec2788a7f6b64137985c087188a54ad4f","https://git.kernel.org/stable/c/d215d09606b0fcd18ad1eb532995782a21cea49d","https://git.kernel.org/stable/c/867119b4b588037724b85839d534465f0334d9bd","https://git.kernel.org/stable/c/3d73a1164a8c6b4461907a65cb6c022ea4fd39af","https://git.kernel.org/stable/c/63811edf512584c946e5e96b100e9e280703bbb5"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:20.145Z"}}},"related_cves":[{"value":"CVE-2026-99078","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6193c77a-b9cb-498e-853b-4f272ad4f8eb","priority":{"reasons":["publisher_severity"],"severity":"critical","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"critical"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99078","advisory_id":"6193c77a-b9cb-498e-853b-4f272ad4f8eb","event_types":["advisory"],"published_at":"2026-10-25T16:10:50.842261+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:25.542+00:00","detail_url":"/advisories/advisory%3A6193c77a-b9cb-498e-853b-4f272ad4f8eb","group":{"id":"advisory:6193c77a-b9cb-498e-853b-4f272ad4f8eb","revision":1,"primary_event_id":55747,"change":"published","superseded_by":[],"changed":{"id":55747,"cve_ids":["CVE-2026-99078"],"payload":{"kind":"advisory","title":"net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry","summary":"In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actual_wq_head is not advanced and a later NAPI poll retries the same WQE. mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On retry it can therefore call xsk_buff_free() again through stale pointers after the frames have returned to the XSK pool and been reallocated. Set all skip_release_bitmap bits in the common error path of mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path. Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AF_XDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings.","evidence":"cve:CVE-2026-99078","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"critical","structured":{"id":"CVE-2026-99078","aliases":["CVE-2026-99078"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":9.8,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - Routable IP packets received by mlx5 consume the AF_XDP striding RQ through mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq(), after which mlx5e_napi_xsk_post() -> mlx5e_post_rx_mpwqes() reaches patched mlx5e_xsk_alloc_rx_mpwqe(); packet pressure exhausts the RX/Fill rings and triggers the stale-buffer retry.\nAC:L - A sender can flood the XSK-bound RSS queue until XDP redirect and refill allocation fail, then continue traffic so NAPI retries the unchanged actual_wq_head; no uncontrolled race is needed for mlx5e_free_rx_mpwqe() to release the stale pointer.\nPR:N - The receive path beginning at mlx5e_completion_event() performs no authentication or capability check; xsk_create()'s CAP_NET_RAW requirement applies to victim-side AF_XDP provisioning, while the remote IP sender needs no privileges.\nUI:N - Once an mlx5 AF_XDP zero-copy pool and XDP program are running, packet receipt, mlx5e_napi_xsk_post(), and the refill retries occur automatically without further victim action.\nS:U - The corrupted xsk_buff_pool metadata and mlx5 receive state belong to the host kernel; the bug crosses no VM, IOMMU, or other security-authority boundary.\nC:H - In unaligned-UMEM mode, duplicate live xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls make xp_release() write kernel pointers past the pool's flexible free_heads[] array; this heap corruption can be leveraged to disclose arbitrary kernel memory.\nI:H - The same xp_release() overflow is an out-of-bounds kernel heap write; subsequent xp_get_xskb() trusts pointers popped from corrupted free_heads[] and initializes through them, supporting arbitrary writes or control-flow corruption.\nA:H - Overflowing free_heads[] or later dereferencing a bogus xskb in xp_get_xskb() can oops or panic; even without a crash, duplicate UMEM ownership can prevent mlx5e_xsk_alloc_rx_mpwqe() from restoring WQEs and stop the bound receive queue."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"f3a52e2ec2788a7f6b64137985c087188a54ad4f","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"d215d09606b0fcd18ad1eb532995782a21cea49d","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"867119b4b588037724b85839d534465f0334d9bd","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"3d73a1164a8c6b4461907a65cb6c022ea4fd39af","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"63811edf512584c946e5e96b100e9e280703bbb5","versionType":"git"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.4"},{"status":"unaffected","version":"0","lessThan":"6.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:20.145Z","provider":"cve","references":["https://git.kernel.org/stable/c/f3a52e2ec2788a7f6b64137985c087188a54ad4f","https://git.kernel.org/stable/c/d215d09606b0fcd18ad1eb532995782a21cea49d","https://git.kernel.org/stable/c/867119b4b588037724b85839d534465f0334d9bd","https://git.kernel.org/stable/c/3d73a1164a8c6b4461907a65cb6c022ea4fd39af","https://git.kernel.org/stable/c/63811edf512584c946e5e96b100e9e280703bbb5"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:20.145Z"}}},"related_cves":[{"value":"CVE-2026-99078","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6193c77a-b9cb-498e-853b-4f272ad4f8eb","priority":{"reasons":["publisher_severity"],"severity":"critical","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"critical"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99078","advisory_id":"6193c77a-b9cb-498e-853b-4f272ad4f8eb","event_types":["advisory"],"published_at":"2026-10-25T16:10:50.842261+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:25.542+00:00","detail_url":"/events/55747"},"members":[{"id":55747,"cve_ids":["CVE-2026-99078"],"payload":{"kind":"advisory","title":"net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry","summary":"In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actual_wq_head is not advanced and a later NAPI poll retries the same WQE. mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On retry it can therefore call xsk_buff_free() again through stale pointers after the frames have returned to the XSK pool and been reallocated. Set all skip_release_bitmap bits in the common error path of mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path. Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AF_XDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings.","evidence":"cve:CVE-2026-99078","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"critical","structured":{"id":"CVE-2026-99078","aliases":["CVE-2026-99078"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":9.8,"baseSeverity":"CRITICAL","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - Routable IP packets received by mlx5 consume the AF_XDP striding RQ through mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq(), after which mlx5e_napi_xsk_post() -> mlx5e_post_rx_mpwqes() reaches patched mlx5e_xsk_alloc_rx_mpwqe(); packet pressure exhausts the RX/Fill rings and triggers the stale-buffer retry.\nAC:L - A sender can flood the XSK-bound RSS queue until XDP redirect and refill allocation fail, then continue traffic so NAPI retries the unchanged actual_wq_head; no uncontrolled race is needed for mlx5e_free_rx_mpwqe() to release the stale pointer.\nPR:N - The receive path beginning at mlx5e_completion_event() performs no authentication or capability check; xsk_create()'s CAP_NET_RAW requirement applies to victim-side AF_XDP provisioning, while the remote IP sender needs no privileges.\nUI:N - Once an mlx5 AF_XDP zero-copy pool and XDP program are running, packet receipt, mlx5e_napi_xsk_post(), and the refill retries occur automatically without further victim action.\nS:U - The corrupted xsk_buff_pool metadata and mlx5 receive state belong to the host kernel; the bug crosses no VM, IOMMU, or other security-authority boundary.\nC:H - In unaligned-UMEM mode, duplicate live xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls make xp_release() write kernel pointers past the pool's flexible free_heads[] array; this heap corruption can be leveraged to disclose arbitrary kernel memory.\nI:H - The same xp_release() overflow is an out-of-bounds kernel heap write; subsequent xp_get_xskb() trusts pointers popped from corrupted free_heads[] and initializes through them, supporting arbitrary writes or control-flow corruption.\nA:H - Overflowing free_heads[] or later dereferencing a bogus xskb in xp_get_xskb() can oops or panic; even without a crash, duplicate UMEM ownership can prevent mlx5e_xsk_alloc_rx_mpwqe() from restoring WQEs and stop the bound receive queue."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"f3a52e2ec2788a7f6b64137985c087188a54ad4f","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"d215d09606b0fcd18ad1eb532995782a21cea49d","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"867119b4b588037724b85839d534465f0334d9bd","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"3d73a1164a8c6b4461907a65cb6c022ea4fd39af","versionType":"git"},{"status":"affected","version":"4c2a1323680709078736a2886c754004e9fe42e6","lessThan":"63811edf512584c946e5e96b100e9e280703bbb5","versionType":"git"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.4"},{"status":"unaffected","version":"0","lessThan":"6.4","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:20.145Z","provider":"cve","references":["https://git.kernel.org/stable/c/f3a52e2ec2788a7f6b64137985c087188a54ad4f","https://git.kernel.org/stable/c/d215d09606b0fcd18ad1eb532995782a21cea49d","https://git.kernel.org/stable/c/867119b4b588037724b85839d534465f0334d9bd","https://git.kernel.org/stable/c/3d73a1164a8c6b4461907a65cb6c022ea4fd39af","https://git.kernel.org/stable/c/63811edf512584c946e5e96b100e9e280703bbb5"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:20.145Z"}}},"related_cves":[{"value":"CVE-2026-99078","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6193c77a-b9cb-498e-853b-4f272ad4f8eb","priority":{"reasons":["publisher_severity"],"severity":"critical","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"critical"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99078","advisory_id":"6193c77a-b9cb-498e-853b-4f272ad4f8eb","event_types":["advisory"],"published_at":"2026-10-25T16:10:50.842261+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:25.542+00:00","detail_url":"/events/55747"}]}},{"id":56222,"cve_ids":["CVE-2026-99064"],"payload":{"kind":"advisory","title":"cipso: adjust cached option offsets when removing CIPSO","summary":"In the Linux kernel, the following vulnerability has been resolved: cipso: adjust cached option offsets when removing CIPSO cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust cached offsets for options that follow them. For example, with a valid 10-byte CIPSO option followed by a seven-byte RR option, parsing records rr at offset 30. Removing CIPSO moves RR to offset 20, while the cached offset remains 30. Consumers such as ip_forward_options() and __ip_options_echo() then access the wrong bytes; the latter may interpret packet data as the option length and copy it into fixed-size option storage. Mirror cipso_v4_delopt() and subtract cipso_len from the srr, rr, ts and router_alert offsets when they follow CIPSO. cipso_len is the distance the first memmove() shifts those options. The later header move and network-header reset relocate the bytes and their offset base together.","evidence":"cve:CVE-2026-99064","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99064","aliases":["CVE-2026-99064"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A remote peer can send an IPv4 datagram containing valid CIPSO followed by RR/TS; ip_rcv()->ip_rcv_options() caches their wire offsets, then selinux_ip_forward()->netlbl_skbuff_setattr()->cipso_v4_skbuff_delattr() removes CIPSO without rebasing them.\nAC:H - The strongest path requires a CONFIG_NETLABEL/SELinux forwarding gateway with network_peer_controls, a recognized CIPSO DOI, an UNLABELED egress mapping, and a later FORWARD REJECT invoking nf_send_unreach(); these non-default conditions are outside the sender's control.\nPR:N - __ip_options_compile() applies CAP_NET_RAW only when skb is NULL; received packets undergo cipso_v4_validate() and SELinux label-policy checks, but require no peer authentication, victim credentials, or target-side privileges.\nUI:N - After the datagram arrives, ip_rcv(), SELinux FORWARD relabeling, and nf_send_unreach()->__ip_options_echo() execute entirely in kernel packet handling without any victim action.\nS:U - The overwrite occurs in __ip_options_echo()'s in-kernel reply-option storage and can compromise the same host kernel; it crosses no VM, IOMMU, or separate security-authority boundary.\nC:H - With stale opt->rr pointing into payload, __ip_options_echo() takes an attacker-chosen length and source bytes and copies up to 255 bytes into 40-byte replyopts.opt.__data; control-flow compromise from this stack overwrite can expose arbitrary kernel memory.\nI:H - The memcpy() can place 255 attacker-controlled payload bytes into the 40-byte stack destination, crossing the stack canary and saved return address in the demonstrated x86-64 layout and enabling kernel control-flow hijacking.\nA:H - The 255-byte __ip_options_echo() stack overwrite triggers KASAN or the stack canary and can panic the kernel; the packet-processing path can be invoked repeatedly with crafted IPv4 datagrams."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"b965977126a90e01825814c859ba4788691eddd3","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"2200fe1d6148b78e1b8f00f4b2bd47760015077f","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"6e49d611a9cfbaac927b8fa80ebd4f6b1f37ada0","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"6d25ffca055a77787c21a36b66c253f76239411b","versionType":"git"}],"programFiles":["net/ipv4/cipso_ipv4.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.10"},{"status":"unaffected","version":"0","lessThan":"6.10","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/ipv4/cipso_ipv4.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:17.979Z","provider":"cve","references":["https://git.kernel.org/stable/c/b965977126a90e01825814c859ba4788691eddd3","https://git.kernel.org/stable/c/2200fe1d6148b78e1b8f00f4b2bd47760015077f","https://git.kernel.org/stable/c/6e49d611a9cfbaac927b8fa80ebd4f6b1f37ada0","https://git.kernel.org/stable/c/6d25ffca055a77787c21a36b66c253f76239411b"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:17.979Z"}}},"related_cves":[{"value":"CVE-2026-99064","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:337ddd09-77a3-4909-a199-bb823ee8819a","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99064","advisory_id":"337ddd09-77a3-4909-a199-bb823ee8819a","event_types":["advisory"],"published_at":"2026-10-25T16:10:50.175979+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:05.854+00:00","detail_url":"/advisories/advisory%3A337ddd09-77a3-4909-a199-bb823ee8819a","group":{"id":"advisory:337ddd09-77a3-4909-a199-bb823ee8819a","revision":1,"primary_event_id":55746,"change":"published","superseded_by":[],"changed":{"id":55746,"cve_ids":["CVE-2026-99064"],"payload":{"kind":"advisory","title":"cipso: adjust cached option offsets when removing CIPSO","summary":"In the Linux kernel, the following vulnerability has been resolved: cipso: adjust cached option offsets when removing CIPSO cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust cached offsets for options that follow them. For example, with a valid 10-byte CIPSO option followed by a seven-byte RR option, parsing records rr at offset 30. Removing CIPSO moves RR to offset 20, while the cached offset remains 30. Consumers such as ip_forward_options() and __ip_options_echo() then access the wrong bytes; the latter may interpret packet data as the option length and copy it into fixed-size option storage. Mirror cipso_v4_delopt() and subtract cipso_len from the srr, rr, ts and router_alert offsets when they follow CIPSO. cipso_len is the distance the first memmove() shifts those options. The later header move and network-header reset relocate the bytes and their offset base together.","evidence":"cve:CVE-2026-99064","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99064","aliases":["CVE-2026-99064"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A remote peer can send an IPv4 datagram containing valid CIPSO followed by RR/TS; ip_rcv()->ip_rcv_options() caches their wire offsets, then selinux_ip_forward()->netlbl_skbuff_setattr()->cipso_v4_skbuff_delattr() removes CIPSO without rebasing them.\nAC:H - The strongest path requires a CONFIG_NETLABEL/SELinux forwarding gateway with network_peer_controls, a recognized CIPSO DOI, an UNLABELED egress mapping, and a later FORWARD REJECT invoking nf_send_unreach(); these non-default conditions are outside the sender's control.\nPR:N - __ip_options_compile() applies CAP_NET_RAW only when skb is NULL; received packets undergo cipso_v4_validate() and SELinux label-policy checks, but require no peer authentication, victim credentials, or target-side privileges.\nUI:N - After the datagram arrives, ip_rcv(), SELinux FORWARD relabeling, and nf_send_unreach()->__ip_options_echo() execute entirely in kernel packet handling without any victim action.\nS:U - The overwrite occurs in __ip_options_echo()'s in-kernel reply-option storage and can compromise the same host kernel; it crosses no VM, IOMMU, or separate security-authority boundary.\nC:H - With stale opt->rr pointing into payload, __ip_options_echo() takes an attacker-chosen length and source bytes and copies up to 255 bytes into 40-byte replyopts.opt.__data; control-flow compromise from this stack overwrite can expose arbitrary kernel memory.\nI:H - The memcpy() can place 255 attacker-controlled payload bytes into the 40-byte stack destination, crossing the stack canary and saved return address in the demonstrated x86-64 layout and enabling kernel control-flow hijacking.\nA:H - The 255-byte __ip_options_echo() stack overwrite triggers KASAN or the stack canary and can panic the kernel; the packet-processing path can be invoked repeatedly with crafted IPv4 datagrams."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"b965977126a90e01825814c859ba4788691eddd3","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"2200fe1d6148b78e1b8f00f4b2bd47760015077f","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"6e49d611a9cfbaac927b8fa80ebd4f6b1f37ada0","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"6d25ffca055a77787c21a36b66c253f76239411b","versionType":"git"}],"programFiles":["net/ipv4/cipso_ipv4.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.10"},{"status":"unaffected","version":"0","lessThan":"6.10","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/ipv4/cipso_ipv4.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:17.979Z","provider":"cve","references":["https://git.kernel.org/stable/c/b965977126a90e01825814c859ba4788691eddd3","https://git.kernel.org/stable/c/2200fe1d6148b78e1b8f00f4b2bd47760015077f","https://git.kernel.org/stable/c/6e49d611a9cfbaac927b8fa80ebd4f6b1f37ada0","https://git.kernel.org/stable/c/6d25ffca055a77787c21a36b66c253f76239411b"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:17.979Z"}}},"related_cves":[{"value":"CVE-2026-99064","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:337ddd09-77a3-4909-a199-bb823ee8819a","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99064","advisory_id":"337ddd09-77a3-4909-a199-bb823ee8819a","event_types":["advisory"],"published_at":"2026-10-25T16:10:50.175979+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:05.854+00:00","detail_url":"/events/55746"},"members":[{"id":55746,"cve_ids":["CVE-2026-99064"],"payload":{"kind":"advisory","title":"cipso: adjust cached option offsets when removing CIPSO","summary":"In the Linux kernel, the following vulnerability has been resolved: cipso: adjust cached option offsets when removing CIPSO cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust cached offsets for options that follow them. For example, with a valid 10-byte CIPSO option followed by a seven-byte RR option, parsing records rr at offset 30. Removing CIPSO moves RR to offset 20, while the cached offset remains 30. Consumers such as ip_forward_options() and __ip_options_echo() then access the wrong bytes; the latter may interpret packet data as the option length and copy it into fixed-size option storage. Mirror cipso_v4_delopt() and subtract cipso_len from the srr, rr, ts and router_alert offsets when they follow CIPSO. cipso_len is the distance the first memmove() shifts those options. The later header move and network-header reset relocate the bytes and their offset base together.","evidence":"cve:CVE-2026-99064","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99064","aliases":["CVE-2026-99064"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A remote peer can send an IPv4 datagram containing valid CIPSO followed by RR/TS; ip_rcv()->ip_rcv_options() caches their wire offsets, then selinux_ip_forward()->netlbl_skbuff_setattr()->cipso_v4_skbuff_delattr() removes CIPSO without rebasing them.\nAC:H - The strongest path requires a CONFIG_NETLABEL/SELinux forwarding gateway with network_peer_controls, a recognized CIPSO DOI, an UNLABELED egress mapping, and a later FORWARD REJECT invoking nf_send_unreach(); these non-default conditions are outside the sender's control.\nPR:N - __ip_options_compile() applies CAP_NET_RAW only when skb is NULL; received packets undergo cipso_v4_validate() and SELinux label-policy checks, but require no peer authentication, victim credentials, or target-side privileges.\nUI:N - After the datagram arrives, ip_rcv(), SELinux FORWARD relabeling, and nf_send_unreach()->__ip_options_echo() execute entirely in kernel packet handling without any victim action.\nS:U - The overwrite occurs in __ip_options_echo()'s in-kernel reply-option storage and can compromise the same host kernel; it crosses no VM, IOMMU, or separate security-authority boundary.\nC:H - With stale opt->rr pointing into payload, __ip_options_echo() takes an attacker-chosen length and source bytes and copies up to 255 bytes into 40-byte replyopts.opt.__data; control-flow compromise from this stack overwrite can expose arbitrary kernel memory.\nI:H - The memcpy() can place 255 attacker-controlled payload bytes into the 40-byte stack destination, crossing the stack canary and saved return address in the demonstrated x86-64 layout and enabling kernel control-flow hijacking.\nA:H - The 255-byte __ip_options_echo() stack overwrite triggers KASAN or the stack canary and can panic the kernel; the packet-processing path can be invoked repeatedly with crafted IPv4 datagrams."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"b965977126a90e01825814c859ba4788691eddd3","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"2200fe1d6148b78e1b8f00f4b2bd47760015077f","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"6e49d611a9cfbaac927b8fa80ebd4f6b1f37ada0","versionType":"git"},{"status":"affected","version":"89aa3619d141d6cfb6040a561aebb6d99d3e2285","lessThan":"6d25ffca055a77787c21a36b66c253f76239411b","versionType":"git"}],"programFiles":["net/ipv4/cipso_ipv4.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.10"},{"status":"unaffected","version":"0","lessThan":"6.10","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/ipv4/cipso_ipv4.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:17.979Z","provider":"cve","references":["https://git.kernel.org/stable/c/b965977126a90e01825814c859ba4788691eddd3","https://git.kernel.org/stable/c/2200fe1d6148b78e1b8f00f4b2bd47760015077f","https://git.kernel.org/stable/c/6e49d611a9cfbaac927b8fa80ebd4f6b1f37ada0","https://git.kernel.org/stable/c/6d25ffca055a77787c21a36b66c253f76239411b"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:17.979Z"}}},"related_cves":[{"value":"CVE-2026-99064","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:337ddd09-77a3-4909-a199-bb823ee8819a","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99064","advisory_id":"337ddd09-77a3-4909-a199-bb823ee8819a","event_types":["advisory"],"published_at":"2026-10-25T16:10:50.175979+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:23:05.854+00:00","detail_url":"/events/55746"}]}},{"id":56221,"cve_ids":["CVE-2026-99059"],"payload":{"kind":"advisory","title":"wireguard: noise: reject response consumption after intermediate initiation","summary":"In the Linux kernel, the following vulnerability has been resolved: wireguard: noise: reject response consumption after intermediate initiation Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire down_write(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A. Thread A Thread B Thread C down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail ","evidence":"cve:CVE-2026-99059","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99059","aliases":["CVE-2026-99059"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.7,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L"},"scenarios":[{"lang":"en","value":"AV:N - An IPv4/IPv6 UDP MESSAGE_HANDSHAKE_RESPONSE follows wg_receive() -> wg_packet_receive() -> wg_packet_handshake_receive_worker() -> wg_receive_handshake_packet() -> patched wg_noise_handshake_consume_response(); replayed response bytes drive the race over a routable WireGuard endpoint.\nAC:H - Success requires responses A and B to snapshot the same initiation while a jittered retransmission has queued C, followed by the exact A-to-C-to-B write-lock ordering. The random REKEY_TIMEOUT jitter and host worker scheduling are not controlled by the attacker.\nPR:N - A byte-identical captured response passes wg_cookie_validate_packet() and the encrypted_nothing check in message_decrypt() when replayed, so an on-path attacker need not possess a configured peer's private or preshared key.\nUI:N - The attacker delays and duplicates the UDP response, while wg_expired_retransmit_handshake() automatically queues the intermediate initiation; no victim action is required during exploitation.\nS:U - The duplicate sessions remain within the same peer's noise_keypairs and compromise traffic handled by that WireGuard device under the same kernel security authority; no VM, IOMMU, or other authority boundary is crossed.\nC:H - Both calls to wg_noise_handshake_begin_session() run derive_keys() on the same chaining_key, while each keypair_create() starts sending_counter at zero. Reusing ChaCha20 keys and nonces across transport packets can expose substantial tunnel plaintext.\nI:H - encrypt_packet() authenticates transport ciphertext with ChaCha20-Poly1305 using the duplicated key and reset counter as its nonce. Reusing that Poly1305 one-time key permits an on-path attacker to construct forged authenticated tunnel packets for colliding counters.\nA:L - The reset sending_counter repeats counters already used by the first session, so the peer's counter_validate() replay window discards colliding packets until the new counter catches up or a rekey occurs. This interrupts tunnel traffic but does not corrupt memory or crash the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"fb5ce4c7790c3eeec820302d08d70ecf46af4295","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"c76a80db593096edf2b3b3972f58b6342a8c6c04","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"4d64a3d6e96aa78619c9c29ffde309794974588a","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"3bec3d32c2a3afd164fc87f95457df2cf9049c20","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"d0305f8d90029556260c6824b61c493c424eba9e","versionType":"git"}],"programFiles":["drivers/net/wireguard/noise.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.6"},{"status":"unaffected","version":"0","lessThan":"5.6","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/wireguard/noise.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:16.832Z","provider":"cve","references":["https://git.kernel.org/stable/c/fb5ce4c7790c3eeec820302d08d70ecf46af4295","https://git.kernel.org/stable/c/c76a80db593096edf2b3b3972f58b6342a8c6c04","https://git.kernel.org/stable/c/4d64a3d6e96aa78619c9c29ffde309794974588a","https://git.kernel.org/stable/c/3bec3d32c2a3afd164fc87f95457df2cf9049c20","https://git.kernel.org/stable/c/d0305f8d90029556260c6824b61c493c424eba9e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:16.832Z"}}},"related_cves":[{"value":"CVE-2026-99059","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99059","advisory_id":"3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","event_types":["advisory"],"published_at":"2026-10-25T16:10:49.499209+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:47.559+00:00","detail_url":"/advisories/advisory%3A3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","group":{"id":"advisory:3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","revision":1,"primary_event_id":55745,"change":"published","superseded_by":[],"changed":{"id":55745,"cve_ids":["CVE-2026-99059"],"payload":{"kind":"advisory","title":"wireguard: noise: reject response consumption after intermediate initiation","summary":"In the Linux kernel, the following vulnerability has been resolved: wireguard: noise: reject response consumption after intermediate initiation Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire down_write(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A. Thread A Thread B Thread C down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail ","evidence":"cve:CVE-2026-99059","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99059","aliases":["CVE-2026-99059"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.7,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L"},"scenarios":[{"lang":"en","value":"AV:N - An IPv4/IPv6 UDP MESSAGE_HANDSHAKE_RESPONSE follows wg_receive() -> wg_packet_receive() -> wg_packet_handshake_receive_worker() -> wg_receive_handshake_packet() -> patched wg_noise_handshake_consume_response(); replayed response bytes drive the race over a routable WireGuard endpoint.\nAC:H - Success requires responses A and B to snapshot the same initiation while a jittered retransmission has queued C, followed by the exact A-to-C-to-B write-lock ordering. The random REKEY_TIMEOUT jitter and host worker scheduling are not controlled by the attacker.\nPR:N - A byte-identical captured response passes wg_cookie_validate_packet() and the encrypted_nothing check in message_decrypt() when replayed, so an on-path attacker need not possess a configured peer's private or preshared key.\nUI:N - The attacker delays and duplicates the UDP response, while wg_expired_retransmit_handshake() automatically queues the intermediate initiation; no victim action is required during exploitation.\nS:U - The duplicate sessions remain within the same peer's noise_keypairs and compromise traffic handled by that WireGuard device under the same kernel security authority; no VM, IOMMU, or other authority boundary is crossed.\nC:H - Both calls to wg_noise_handshake_begin_session() run derive_keys() on the same chaining_key, while each keypair_create() starts sending_counter at zero. Reusing ChaCha20 keys and nonces across transport packets can expose substantial tunnel plaintext.\nI:H - encrypt_packet() authenticates transport ciphertext with ChaCha20-Poly1305 using the duplicated key and reset counter as its nonce. Reusing that Poly1305 one-time key permits an on-path attacker to construct forged authenticated tunnel packets for colliding counters.\nA:L - The reset sending_counter repeats counters already used by the first session, so the peer's counter_validate() replay window discards colliding packets until the new counter catches up or a rekey occurs. This interrupts tunnel traffic but does not corrupt memory or crash the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"fb5ce4c7790c3eeec820302d08d70ecf46af4295","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"c76a80db593096edf2b3b3972f58b6342a8c6c04","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"4d64a3d6e96aa78619c9c29ffde309794974588a","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"3bec3d32c2a3afd164fc87f95457df2cf9049c20","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"d0305f8d90029556260c6824b61c493c424eba9e","versionType":"git"}],"programFiles":["drivers/net/wireguard/noise.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.6"},{"status":"unaffected","version":"0","lessThan":"5.6","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/wireguard/noise.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:16.832Z","provider":"cve","references":["https://git.kernel.org/stable/c/fb5ce4c7790c3eeec820302d08d70ecf46af4295","https://git.kernel.org/stable/c/c76a80db593096edf2b3b3972f58b6342a8c6c04","https://git.kernel.org/stable/c/4d64a3d6e96aa78619c9c29ffde309794974588a","https://git.kernel.org/stable/c/3bec3d32c2a3afd164fc87f95457df2cf9049c20","https://git.kernel.org/stable/c/d0305f8d90029556260c6824b61c493c424eba9e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:16.832Z"}}},"related_cves":[{"value":"CVE-2026-99059","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99059","advisory_id":"3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","event_types":["advisory"],"published_at":"2026-10-25T16:10:49.499209+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:47.559+00:00","detail_url":"/events/55745"},"members":[{"id":55745,"cve_ids":["CVE-2026-99059"],"payload":{"kind":"advisory","title":"wireguard: noise: reject response consumption after intermediate initiation","summary":"In the Linux kernel, the following vulnerability has been resolved: wireguard: noise: reject response consumption after intermediate initiation Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which point thread B resumes, because either its finished its calculations or was finally allowed to acquire down_write(). Thread B then copies the state back to the peer, and begins a new session, using that state, which is the same session as the one made in thread A. Thread A Thread B Thread C down_read() sA = handshake->state memcpy(cA, handshake->crypto) up_read() if (sA != 1) goto fail slow_crypto(cA) down_read() sB = handshake->state memcpy(cB, handshake->crypto) up_read() if (sB != 1) goto fail slow_crypto(cB) down_write() if (sA != handshake->state) goto fail memcpy(handshake->crypto, cA) handshake->state = 2 up_write() down_write() if (handshake->state != 2) goto fail derive_session(handshake->crypto) up_write() down_write() slow_crypto(handshake->crypto) handshake->state = 1 up_write() down_write() if (sB != handshake->state) goto fail ","evidence":"cve:CVE-2026-99059","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99059","aliases":["CVE-2026-99059"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.7,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L"},"scenarios":[{"lang":"en","value":"AV:N - An IPv4/IPv6 UDP MESSAGE_HANDSHAKE_RESPONSE follows wg_receive() -> wg_packet_receive() -> wg_packet_handshake_receive_worker() -> wg_receive_handshake_packet() -> patched wg_noise_handshake_consume_response(); replayed response bytes drive the race over a routable WireGuard endpoint.\nAC:H - Success requires responses A and B to snapshot the same initiation while a jittered retransmission has queued C, followed by the exact A-to-C-to-B write-lock ordering. The random REKEY_TIMEOUT jitter and host worker scheduling are not controlled by the attacker.\nPR:N - A byte-identical captured response passes wg_cookie_validate_packet() and the encrypted_nothing check in message_decrypt() when replayed, so an on-path attacker need not possess a configured peer's private or preshared key.\nUI:N - The attacker delays and duplicates the UDP response, while wg_expired_retransmit_handshake() automatically queues the intermediate initiation; no victim action is required during exploitation.\nS:U - The duplicate sessions remain within the same peer's noise_keypairs and compromise traffic handled by that WireGuard device under the same kernel security authority; no VM, IOMMU, or other authority boundary is crossed.\nC:H - Both calls to wg_noise_handshake_begin_session() run derive_keys() on the same chaining_key, while each keypair_create() starts sending_counter at zero. Reusing ChaCha20 keys and nonces across transport packets can expose substantial tunnel plaintext.\nI:H - encrypt_packet() authenticates transport ciphertext with ChaCha20-Poly1305 using the duplicated key and reset counter as its nonce. Reusing that Poly1305 one-time key permits an on-path attacker to construct forged authenticated tunnel packets for colliding counters.\nA:L - The reset sending_counter repeats counters already used by the first session, so the peer's counter_validate() replay window discards colliding packets until the new counter catches up or a rekey occurs. This interrupts tunnel traffic but does not corrupt memory or crash the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"fb5ce4c7790c3eeec820302d08d70ecf46af4295","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"c76a80db593096edf2b3b3972f58b6342a8c6c04","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"4d64a3d6e96aa78619c9c29ffde309794974588a","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"3bec3d32c2a3afd164fc87f95457df2cf9049c20","versionType":"git"},{"status":"affected","version":"e7096c131e5161fa3b8e52a650d7719d2857adfd","lessThan":"d0305f8d90029556260c6824b61c493c424eba9e","versionType":"git"}],"programFiles":["drivers/net/wireguard/noise.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.6"},{"status":"unaffected","version":"0","lessThan":"5.6","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/wireguard/noise.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:16.832Z","provider":"cve","references":["https://git.kernel.org/stable/c/fb5ce4c7790c3eeec820302d08d70ecf46af4295","https://git.kernel.org/stable/c/c76a80db593096edf2b3b3972f58b6342a8c6c04","https://git.kernel.org/stable/c/4d64a3d6e96aa78619c9c29ffde309794974588a","https://git.kernel.org/stable/c/3bec3d32c2a3afd164fc87f95457df2cf9049c20","https://git.kernel.org/stable/c/d0305f8d90029556260c6824b61c493c424eba9e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:16.832Z"}}},"related_cves":[{"value":"CVE-2026-99059","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99059","advisory_id":"3c5d912b-a5cf-4cfb-ac5e-c3cfe08cf983","event_types":["advisory"],"published_at":"2026-10-25T16:10:49.499209+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:47.559+00:00","detail_url":"/events/55745"}]}},{"id":56220,"cve_ids":["CVE-2026-99056"],"payload":{"kind":"advisory","title":"strparser: make sure __strp_recv isn't running before tearing down the parser","summary":"In the Linux kernel, the following vulnerability has been resolved: strparser: make sure __strp_recv isn't running before tearing down the parser The comment above strp_done() claims that if strp is stopped, strp_recv will no longer be called. That's only true if the caller has a mechanism (eg locking) to guarantee that strp_recv() calls that started before strp_stop() have completed by the time we call strp_done(). This adds a dummy lock_sock/release_sock pair to guarantee that any in-flight strp_recv() (which runs under either bh_lock_sock or lock_sock, depending if it's called from ->sk_data_ready or strp_work) has completed. Only espintcp can be affected by this race condition, but this patch makes sure no future user of strp can have the bug. This could crash on strp->sk (\"general mode\" of strp), but this mode has been here for 9 years and has never been used. It'll be gone soon, no point worrying about it. Switch the stopped/paused/etc bits to u8's to avoid races between strp_stop() and strp_pause/unpause(). A reproducer has been published and turns the possible UAF into an exploit [1].","evidence":"cve:CVE-2026-99056","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99056","aliases":["CVE-2026-99056"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - An unprivileged local process can attach \"espintcp\" with setsockopt(TCP_ULP), then use a loopback peer to drive espintcp_data_ready()->strp_data_ready()->__strp_recv() while close() reaches espintcp_close()->strp_done(); a network peer alone cannot initiate the required local teardown.\nAC:L - The same process controls both race sides: it sets a finite SO_RCVTIMEO, sends complete keepalives plus a partial header that makes espintcp_parse() return 0 and strp_start_timer() rearm after strp_done() cancels, and concurrently closes the target socket. The race is repeatable and publicly exploited.\nPR:L - __sys_setsockopt()->tcp_setsockopt()->tcp_set_ulp()->espintcp_init_sk() contains no capability or authentication check for an already registered \"espintcp\" ULP. An ordinary local user can create the TCP pair, set the timeout, attach the ULP, and close it.\nUI:N - The attacking process performs the socket creation, TCP_ULP attachment, traffic generation, close, and heap reclaim itself; no action by another user is required.\nS:U - The reclaimed espintcp_ctx and its msg_timer_work execute within the host kernel reached by the attacking local process; this is a conventional local kernel privilege escalation and crosses no VM, IOMMU, or separate security authority.\nC:H - The freed espintcp_ctx can be reclaimed with a controlled user_key_payload, including msg_timer_work.timer.function and callback operands. The resulting kernel callback control and root execution permit access to arbitrary protected memory.\nI:H - The controlled timer.function and RDI-relative operands let the demonstrated iocg_flush_stat_upward gadget perform a chosen delta write to modprobe_path, producing root code execution.\nA:H - If the freed msg_timer_work is not coherently reclaimed, timer expiry consumes stale work_struct fields or calls an invalid timer.function, causing a kernel fault or panic; the published exploit also documents a crash-only variant."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"a18dd388045dc7263d99a07db9de4e0f149ca8f1","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"9f3e9fe1b155e9b4572054d8d140586bc3512ecf","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"d2b5f637b9b67a79a50d42614d10653c13b4e449","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"eaa3a29004c063d7e9d5ea55636f693f67e6db0f","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"0984ebc631792acf8fff105112ee74a6b8f1efcc","versionType":"git"}],"programFiles":["Documentation/networking/strparser.rst","include/net/strparser.h","net/strparser/strparser.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.6"},{"status":"unaffected","version":"0","lessThan":"5.6","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["Documentation/networking/strparser.rst","include/net/strparser.h","net/strparser/strparser.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:15.756Z","provider":"cve","references":["https://git.kernel.org/stable/c/a18dd388045dc7263d99a07db9de4e0f149ca8f1","https://git.kernel.org/stable/c/9f3e9fe1b155e9b4572054d8d140586bc3512ecf","https://git.kernel.org/stable/c/d2b5f637b9b67a79a50d42614d10653c13b4e449","https://git.kernel.org/stable/c/eaa3a29004c063d7e9d5ea55636f693f67e6db0f","https://git.kernel.org/stable/c/0984ebc631792acf8fff105112ee74a6b8f1efcc"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:15.756Z"}}},"related_cves":[{"value":"CVE-2026-99056","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:41383741-d692-4556-b99d-910a9c277f8c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99056","advisory_id":"41383741-d692-4556-b99d-910a9c277f8c","event_types":["advisory"],"published_at":"2026-10-25T16:10:48.642963+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:42.234+00:00","detail_url":"/advisories/advisory%3A41383741-d692-4556-b99d-910a9c277f8c","group":{"id":"advisory:41383741-d692-4556-b99d-910a9c277f8c","revision":1,"primary_event_id":55744,"change":"published","superseded_by":[],"changed":{"id":55744,"cve_ids":["CVE-2026-99056"],"payload":{"kind":"advisory","title":"strparser: make sure __strp_recv isn't running before tearing down the parser","summary":"In the Linux kernel, the following vulnerability has been resolved: strparser: make sure __strp_recv isn't running before tearing down the parser The comment above strp_done() claims that if strp is stopped, strp_recv will no longer be called. That's only true if the caller has a mechanism (eg locking) to guarantee that strp_recv() calls that started before strp_stop() have completed by the time we call strp_done(). This adds a dummy lock_sock/release_sock pair to guarantee that any in-flight strp_recv() (which runs under either bh_lock_sock or lock_sock, depending if it's called from ->sk_data_ready or strp_work) has completed. Only espintcp can be affected by this race condition, but this patch makes sure no future user of strp can have the bug. This could crash on strp->sk (\"general mode\" of strp), but this mode has been here for 9 years and has never been used. It'll be gone soon, no point worrying about it. Switch the stopped/paused/etc bits to u8's to avoid races between strp_stop() and strp_pause/unpause(). A reproducer has been published and turns the possible UAF into an exploit [1].","evidence":"cve:CVE-2026-99056","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99056","aliases":["CVE-2026-99056"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - An unprivileged local process can attach \"espintcp\" with setsockopt(TCP_ULP), then use a loopback peer to drive espintcp_data_ready()->strp_data_ready()->__strp_recv() while close() reaches espintcp_close()->strp_done(); a network peer alone cannot initiate the required local teardown.\nAC:L - The same process controls both race sides: it sets a finite SO_RCVTIMEO, sends complete keepalives plus a partial header that makes espintcp_parse() return 0 and strp_start_timer() rearm after strp_done() cancels, and concurrently closes the target socket. The race is repeatable and publicly exploited.\nPR:L - __sys_setsockopt()->tcp_setsockopt()->tcp_set_ulp()->espintcp_init_sk() contains no capability or authentication check for an already registered \"espintcp\" ULP. An ordinary local user can create the TCP pair, set the timeout, attach the ULP, and close it.\nUI:N - The attacking process performs the socket creation, TCP_ULP attachment, traffic generation, close, and heap reclaim itself; no action by another user is required.\nS:U - The reclaimed espintcp_ctx and its msg_timer_work execute within the host kernel reached by the attacking local process; this is a conventional local kernel privilege escalation and crosses no VM, IOMMU, or separate security authority.\nC:H - The freed espintcp_ctx can be reclaimed with a controlled user_key_payload, including msg_timer_work.timer.function and callback operands. The resulting kernel callback control and root execution permit access to arbitrary protected memory.\nI:H - The controlled timer.function and RDI-relative operands let the demonstrated iocg_flush_stat_upward gadget perform a chosen delta write to modprobe_path, producing root code execution.\nA:H - If the freed msg_timer_work is not coherently reclaimed, timer expiry consumes stale work_struct fields or calls an invalid timer.function, causing a kernel fault or panic; the published exploit also documents a crash-only variant."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"a18dd388045dc7263d99a07db9de4e0f149ca8f1","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"9f3e9fe1b155e9b4572054d8d140586bc3512ecf","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"d2b5f637b9b67a79a50d42614d10653c13b4e449","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"eaa3a29004c063d7e9d5ea55636f693f67e6db0f","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"0984ebc631792acf8fff105112ee74a6b8f1efcc","versionType":"git"}],"programFiles":["Documentation/networking/strparser.rst","include/net/strparser.h","net/strparser/strparser.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.6"},{"status":"unaffected","version":"0","lessThan":"5.6","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["Documentation/networking/strparser.rst","include/net/strparser.h","net/strparser/strparser.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:15.756Z","provider":"cve","references":["https://git.kernel.org/stable/c/a18dd388045dc7263d99a07db9de4e0f149ca8f1","https://git.kernel.org/stable/c/9f3e9fe1b155e9b4572054d8d140586bc3512ecf","https://git.kernel.org/stable/c/d2b5f637b9b67a79a50d42614d10653c13b4e449","https://git.kernel.org/stable/c/eaa3a29004c063d7e9d5ea55636f693f67e6db0f","https://git.kernel.org/stable/c/0984ebc631792acf8fff105112ee74a6b8f1efcc"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:15.756Z"}}},"related_cves":[{"value":"CVE-2026-99056","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:41383741-d692-4556-b99d-910a9c277f8c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99056","advisory_id":"41383741-d692-4556-b99d-910a9c277f8c","event_types":["advisory"],"published_at":"2026-10-25T16:10:48.642963+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:42.234+00:00","detail_url":"/events/55744"},"members":[{"id":55744,"cve_ids":["CVE-2026-99056"],"payload":{"kind":"advisory","title":"strparser: make sure __strp_recv isn't running before tearing down the parser","summary":"In the Linux kernel, the following vulnerability has been resolved: strparser: make sure __strp_recv isn't running before tearing down the parser The comment above strp_done() claims that if strp is stopped, strp_recv will no longer be called. That's only true if the caller has a mechanism (eg locking) to guarantee that strp_recv() calls that started before strp_stop() have completed by the time we call strp_done(). This adds a dummy lock_sock/release_sock pair to guarantee that any in-flight strp_recv() (which runs under either bh_lock_sock or lock_sock, depending if it's called from ->sk_data_ready or strp_work) has completed. Only espintcp can be affected by this race condition, but this patch makes sure no future user of strp can have the bug. This could crash on strp->sk (\"general mode\" of strp), but this mode has been here for 9 years and has never been used. It'll be gone soon, no point worrying about it. Switch the stopped/paused/etc bits to u8's to avoid races between strp_stop() and strp_pause/unpause(). A reproducer has been published and turns the possible UAF into an exploit [1].","evidence":"cve:CVE-2026-99056","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99056","aliases":["CVE-2026-99056"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - An unprivileged local process can attach \"espintcp\" with setsockopt(TCP_ULP), then use a loopback peer to drive espintcp_data_ready()->strp_data_ready()->__strp_recv() while close() reaches espintcp_close()->strp_done(); a network peer alone cannot initiate the required local teardown.\nAC:L - The same process controls both race sides: it sets a finite SO_RCVTIMEO, sends complete keepalives plus a partial header that makes espintcp_parse() return 0 and strp_start_timer() rearm after strp_done() cancels, and concurrently closes the target socket. The race is repeatable and publicly exploited.\nPR:L - __sys_setsockopt()->tcp_setsockopt()->tcp_set_ulp()->espintcp_init_sk() contains no capability or authentication check for an already registered \"espintcp\" ULP. An ordinary local user can create the TCP pair, set the timeout, attach the ULP, and close it.\nUI:N - The attacking process performs the socket creation, TCP_ULP attachment, traffic generation, close, and heap reclaim itself; no action by another user is required.\nS:U - The reclaimed espintcp_ctx and its msg_timer_work execute within the host kernel reached by the attacking local process; this is a conventional local kernel privilege escalation and crosses no VM, IOMMU, or separate security authority.\nC:H - The freed espintcp_ctx can be reclaimed with a controlled user_key_payload, including msg_timer_work.timer.function and callback operands. The resulting kernel callback control and root execution permit access to arbitrary protected memory.\nI:H - The controlled timer.function and RDI-relative operands let the demonstrated iocg_flush_stat_upward gadget perform a chosen delta write to modprobe_path, producing root code execution.\nA:H - If the freed msg_timer_work is not coherently reclaimed, timer expiry consumes stale work_struct fields or calls an invalid timer.function, causing a kernel fault or panic; the published exploit also documents a crash-only variant."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"a18dd388045dc7263d99a07db9de4e0f149ca8f1","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"9f3e9fe1b155e9b4572054d8d140586bc3512ecf","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"d2b5f637b9b67a79a50d42614d10653c13b4e449","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"eaa3a29004c063d7e9d5ea55636f693f67e6db0f","versionType":"git"},{"status":"affected","version":"e27cca96cd68fa2c6814c90f9a1cfd36bb68c593","lessThan":"0984ebc631792acf8fff105112ee74a6b8f1efcc","versionType":"git"}],"programFiles":["Documentation/networking/strparser.rst","include/net/strparser.h","net/strparser/strparser.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.6"},{"status":"unaffected","version":"0","lessThan":"5.6","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["Documentation/networking/strparser.rst","include/net/strparser.h","net/strparser/strparser.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:15.756Z","provider":"cve","references":["https://git.kernel.org/stable/c/a18dd388045dc7263d99a07db9de4e0f149ca8f1","https://git.kernel.org/stable/c/9f3e9fe1b155e9b4572054d8d140586bc3512ecf","https://git.kernel.org/stable/c/d2b5f637b9b67a79a50d42614d10653c13b4e449","https://git.kernel.org/stable/c/eaa3a29004c063d7e9d5ea55636f693f67e6db0f","https://git.kernel.org/stable/c/0984ebc631792acf8fff105112ee74a6b8f1efcc"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:15.756Z"}}},"related_cves":[{"value":"CVE-2026-99056","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:41383741-d692-4556-b99d-910a9c277f8c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99056","advisory_id":"41383741-d692-4556-b99d-910a9c277f8c","event_types":["advisory"],"published_at":"2026-10-25T16:10:48.642963+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:42.234+00:00","detail_url":"/events/55744"}]}},{"id":56219,"cve_ids":["CVE-2026-99054"],"payload":{"kind":"advisory","title":"tipc: destroy topsrv workqueues before closing connections","summary":"In the Linux kernel, the following vulnerability has been resolved: tipc: destroy topsrv workqueues before closing connections tipc_topsrv_stop() closed subscriber connections while the topology server's send and receive workqueues were still running. Socket callbacks and subscription events could then queue more work, and in-flight send/recv work could drop the last connection reference during the conn_idr walk. That race produced several teardown failures: refcount_t addition on 0 from conn_get() on a connection whose release was blocked on idr_lock, a subsequent use-after-free in tipc_conn_close(), queue_work() on an already destroyed workqueue from the listener data-ready callback, and an RCU stall in tipc_topsrv_exit_net() while the walk spun under idr_lock. Clear srv->listener under idr_lock so it acts as a shutdown flag, skip queue_work() once it is NULL, destroy the workqueues to flush in-flight work, and only then close the remaining connections. Refuse tipc_conn_lookup() after that flag is cleared, and drop idr_lock when the teardown walk finds no connection, so an in-flight subscription event cannot pin idr_in_use while the walk holds the lock. v3 supersedes the narrower in-thread diff Tung Quang Nguyen posted on 2026-09-23. It keeps his teardown order and adds the lookup refusal and the empty-idr unlock.","evidence":"cve:CVE-2026-99054","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99054","aliases":["CVE-2026-99054"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `unshare(CLONE_NEWUSER|CLONE_NEWNET)` creates the per-net TIPC server; local `socket(AF_TIPC)`, `connect(TIPC_TOP_SRV)`, and `send()` churn followed by exit drives `cleanup_net()` -> `tipc_topsrv_exit_net()` -> patched `tipc_topsrv_stop()`. No remote message can cause the required namespace teardown.\nAC:L - The attacker controls both sides of the race: worker threads repeatedly create and close topology subscriptions while their process exits the network namespace, racing `rwork`/`swork` and socket callbacks against `tipc_topsrv_stop()`. No victim or hardware state is required.\nPR:L - `tipc_sk_create()`, `tipc_connect()`, and `tipc_conn_rcv_sub()` have no capability or authentication gate; an ordinary user can obtain the `CAP_SYS_ADMIN` needed for `CLONE_NEWNET` inside a new user namespace. No init-namespace privilege is required.\nUI:N - The attacker creates the namespaces, opens and floods `TIPC_TOP_SRV` connections, closes them, and exits to start `cleanup_net()` without any victim action.\nS:U - The freed `tipc_conn` and workqueue objects belong to the host kernel, and exploitation of `tipc_topsrv_stop()` affects that same kernel authority without crossing a VM, IOMMU, or other security boundary.\nC:H - `tipc_conn_kref_release()` frees `con` while teardown retains its address; `tipc_conn_close()` then reads `con->sock->sk` and follows reclaimed subscription and socket pointers. Reclaiming this object permits attacker-controlled pointer dereferences usable as kernel-memory read primitives.\nI:H - After the free, `tipc_conn_close()` modifies reclaimed `con->flags`, writes through `sk->sk_user_data`, processes reclaimed subscription lists, and calls `kernel_sock_shutdown()` through `con->sock->ops`. These provide memory-write and control-flow primitives.\nA:H - The reported race produced a page fault in `tipc_conn_close()`, `queue_work()` on a destroyed receive workqueue, and an RCU stall in `tipc_topsrv_exit_net()`; these paths can oops, panic, or wedge the system."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"7f796bb3b440d7f1b14c0e3b520462eb34f553af","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"da9c16568bc79140a54c1f5fcf07a0305df47b37","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"fb717c536af2aafeca520ff11d1e0f25f7ab8fa9","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"3acdd44385bc7e2e57605e073691ce69cc5a960d","versionType":"git"}],"programFiles":["net/tipc/topsrv.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.11"},{"status":"unaffected","version":"0","lessThan":"3.11","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/tipc/topsrv.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:14.659Z","provider":"cve","references":["https://git.kernel.org/stable/c/7f796bb3b440d7f1b14c0e3b520462eb34f553af","https://git.kernel.org/stable/c/da9c16568bc79140a54c1f5fcf07a0305df47b37","https://git.kernel.org/stable/c/0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e","https://git.kernel.org/stable/c/fb717c536af2aafeca520ff11d1e0f25f7ab8fa9","https://git.kernel.org/stable/c/3acdd44385bc7e2e57605e073691ce69cc5a960d"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:14.659Z"}}},"related_cves":[{"value":"CVE-2026-99054","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:3d0ccc23-747a-4486-92d1-1697a0842e15","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99054","advisory_id":"3d0ccc23-747a-4486-92d1-1697a0842e15","event_types":["advisory"],"published_at":"2026-10-25T16:10:47.965601+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:36.886+00:00","detail_url":"/advisories/advisory%3A3d0ccc23-747a-4486-92d1-1697a0842e15","group":{"id":"advisory:3d0ccc23-747a-4486-92d1-1697a0842e15","revision":1,"primary_event_id":55743,"change":"published","superseded_by":[],"changed":{"id":55743,"cve_ids":["CVE-2026-99054"],"payload":{"kind":"advisory","title":"tipc: destroy topsrv workqueues before closing connections","summary":"In the Linux kernel, the following vulnerability has been resolved: tipc: destroy topsrv workqueues before closing connections tipc_topsrv_stop() closed subscriber connections while the topology server's send and receive workqueues were still running. Socket callbacks and subscription events could then queue more work, and in-flight send/recv work could drop the last connection reference during the conn_idr walk. That race produced several teardown failures: refcount_t addition on 0 from conn_get() on a connection whose release was blocked on idr_lock, a subsequent use-after-free in tipc_conn_close(), queue_work() on an already destroyed workqueue from the listener data-ready callback, and an RCU stall in tipc_topsrv_exit_net() while the walk spun under idr_lock. Clear srv->listener under idr_lock so it acts as a shutdown flag, skip queue_work() once it is NULL, destroy the workqueues to flush in-flight work, and only then close the remaining connections. Refuse tipc_conn_lookup() after that flag is cleared, and drop idr_lock when the teardown walk finds no connection, so an in-flight subscription event cannot pin idr_in_use while the walk holds the lock. v3 supersedes the narrower in-thread diff Tung Quang Nguyen posted on 2026-09-23. It keeps his teardown order and adds the lookup refusal and the empty-idr unlock.","evidence":"cve:CVE-2026-99054","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99054","aliases":["CVE-2026-99054"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `unshare(CLONE_NEWUSER|CLONE_NEWNET)` creates the per-net TIPC server; local `socket(AF_TIPC)`, `connect(TIPC_TOP_SRV)`, and `send()` churn followed by exit drives `cleanup_net()` -> `tipc_topsrv_exit_net()` -> patched `tipc_topsrv_stop()`. No remote message can cause the required namespace teardown.\nAC:L - The attacker controls both sides of the race: worker threads repeatedly create and close topology subscriptions while their process exits the network namespace, racing `rwork`/`swork` and socket callbacks against `tipc_topsrv_stop()`. No victim or hardware state is required.\nPR:L - `tipc_sk_create()`, `tipc_connect()`, and `tipc_conn_rcv_sub()` have no capability or authentication gate; an ordinary user can obtain the `CAP_SYS_ADMIN` needed for `CLONE_NEWNET` inside a new user namespace. No init-namespace privilege is required.\nUI:N - The attacker creates the namespaces, opens and floods `TIPC_TOP_SRV` connections, closes them, and exits to start `cleanup_net()` without any victim action.\nS:U - The freed `tipc_conn` and workqueue objects belong to the host kernel, and exploitation of `tipc_topsrv_stop()` affects that same kernel authority without crossing a VM, IOMMU, or other security boundary.\nC:H - `tipc_conn_kref_release()` frees `con` while teardown retains its address; `tipc_conn_close()` then reads `con->sock->sk` and follows reclaimed subscription and socket pointers. Reclaiming this object permits attacker-controlled pointer dereferences usable as kernel-memory read primitives.\nI:H - After the free, `tipc_conn_close()` modifies reclaimed `con->flags`, writes through `sk->sk_user_data`, processes reclaimed subscription lists, and calls `kernel_sock_shutdown()` through `con->sock->ops`. These provide memory-write and control-flow primitives.\nA:H - The reported race produced a page fault in `tipc_conn_close()`, `queue_work()` on a destroyed receive workqueue, and an RCU stall in `tipc_topsrv_exit_net()`; these paths can oops, panic, or wedge the system."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"7f796bb3b440d7f1b14c0e3b520462eb34f553af","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"da9c16568bc79140a54c1f5fcf07a0305df47b37","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"fb717c536af2aafeca520ff11d1e0f25f7ab8fa9","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"3acdd44385bc7e2e57605e073691ce69cc5a960d","versionType":"git"}],"programFiles":["net/tipc/topsrv.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.11"},{"status":"unaffected","version":"0","lessThan":"3.11","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/tipc/topsrv.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:14.659Z","provider":"cve","references":["https://git.kernel.org/stable/c/7f796bb3b440d7f1b14c0e3b520462eb34f553af","https://git.kernel.org/stable/c/da9c16568bc79140a54c1f5fcf07a0305df47b37","https://git.kernel.org/stable/c/0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e","https://git.kernel.org/stable/c/fb717c536af2aafeca520ff11d1e0f25f7ab8fa9","https://git.kernel.org/stable/c/3acdd44385bc7e2e57605e073691ce69cc5a960d"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:14.659Z"}}},"related_cves":[{"value":"CVE-2026-99054","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:3d0ccc23-747a-4486-92d1-1697a0842e15","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99054","advisory_id":"3d0ccc23-747a-4486-92d1-1697a0842e15","event_types":["advisory"],"published_at":"2026-10-25T16:10:47.965601+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:36.886+00:00","detail_url":"/events/55743"},"members":[{"id":55743,"cve_ids":["CVE-2026-99054"],"payload":{"kind":"advisory","title":"tipc: destroy topsrv workqueues before closing connections","summary":"In the Linux kernel, the following vulnerability has been resolved: tipc: destroy topsrv workqueues before closing connections tipc_topsrv_stop() closed subscriber connections while the topology server's send and receive workqueues were still running. Socket callbacks and subscription events could then queue more work, and in-flight send/recv work could drop the last connection reference during the conn_idr walk. That race produced several teardown failures: refcount_t addition on 0 from conn_get() on a connection whose release was blocked on idr_lock, a subsequent use-after-free in tipc_conn_close(), queue_work() on an already destroyed workqueue from the listener data-ready callback, and an RCU stall in tipc_topsrv_exit_net() while the walk spun under idr_lock. Clear srv->listener under idr_lock so it acts as a shutdown flag, skip queue_work() once it is NULL, destroy the workqueues to flush in-flight work, and only then close the remaining connections. Refuse tipc_conn_lookup() after that flag is cleared, and drop idr_lock when the teardown walk finds no connection, so an in-flight subscription event cannot pin idr_in_use while the walk holds the lock. v3 supersedes the narrower in-thread diff Tung Quang Nguyen posted on 2026-09-23. It keeps his teardown order and adds the lookup refusal and the empty-idr unlock.","evidence":"cve:CVE-2026-99054","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99054","aliases":["CVE-2026-99054"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `unshare(CLONE_NEWUSER|CLONE_NEWNET)` creates the per-net TIPC server; local `socket(AF_TIPC)`, `connect(TIPC_TOP_SRV)`, and `send()` churn followed by exit drives `cleanup_net()` -> `tipc_topsrv_exit_net()` -> patched `tipc_topsrv_stop()`. No remote message can cause the required namespace teardown.\nAC:L - The attacker controls both sides of the race: worker threads repeatedly create and close topology subscriptions while their process exits the network namespace, racing `rwork`/`swork` and socket callbacks against `tipc_topsrv_stop()`. No victim or hardware state is required.\nPR:L - `tipc_sk_create()`, `tipc_connect()`, and `tipc_conn_rcv_sub()` have no capability or authentication gate; an ordinary user can obtain the `CAP_SYS_ADMIN` needed for `CLONE_NEWNET` inside a new user namespace. No init-namespace privilege is required.\nUI:N - The attacker creates the namespaces, opens and floods `TIPC_TOP_SRV` connections, closes them, and exits to start `cleanup_net()` without any victim action.\nS:U - The freed `tipc_conn` and workqueue objects belong to the host kernel, and exploitation of `tipc_topsrv_stop()` affects that same kernel authority without crossing a VM, IOMMU, or other security boundary.\nC:H - `tipc_conn_kref_release()` frees `con` while teardown retains its address; `tipc_conn_close()` then reads `con->sock->sk` and follows reclaimed subscription and socket pointers. Reclaiming this object permits attacker-controlled pointer dereferences usable as kernel-memory read primitives.\nI:H - After the free, `tipc_conn_close()` modifies reclaimed `con->flags`, writes through `sk->sk_user_data`, processes reclaimed subscription lists, and calls `kernel_sock_shutdown()` through `con->sock->ops`. These provide memory-write and control-flow primitives.\nA:H - The reported race produced a page fault in `tipc_conn_close()`, `queue_work()` on a destroyed receive workqueue, and an RCU stall in `tipc_topsrv_exit_net()`; these paths can oops, panic, or wedge the system."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"7f796bb3b440d7f1b14c0e3b520462eb34f553af","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"da9c16568bc79140a54c1f5fcf07a0305df47b37","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"fb717c536af2aafeca520ff11d1e0f25f7ab8fa9","versionType":"git"},{"status":"affected","version":"c5fa7b3cf3cb22e4ac60485fc2dc187fe012910f","lessThan":"3acdd44385bc7e2e57605e073691ce69cc5a960d","versionType":"git"}],"programFiles":["net/tipc/topsrv.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.11"},{"status":"unaffected","version":"0","lessThan":"3.11","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/tipc/topsrv.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:14.659Z","provider":"cve","references":["https://git.kernel.org/stable/c/7f796bb3b440d7f1b14c0e3b520462eb34f553af","https://git.kernel.org/stable/c/da9c16568bc79140a54c1f5fcf07a0305df47b37","https://git.kernel.org/stable/c/0af8780bdfdfc91fb9127bddb9c48fab67dc9d9e","https://git.kernel.org/stable/c/fb717c536af2aafeca520ff11d1e0f25f7ab8fa9","https://git.kernel.org/stable/c/3acdd44385bc7e2e57605e073691ce69cc5a960d"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:14.659Z"}}},"related_cves":[{"value":"CVE-2026-99054","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:3d0ccc23-747a-4486-92d1-1697a0842e15","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99054","advisory_id":"3d0ccc23-747a-4486-92d1-1697a0842e15","event_types":["advisory"],"published_at":"2026-10-25T16:10:47.965601+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:36.886+00:00","detail_url":"/events/55743"}]}},{"id":56218,"cve_ids":["CVE-2026-99053"],"payload":{"kind":"advisory","title":"tipc: hold a reference to nodes found by link name","summary":"In the Linux kernel, the following vulnerability has been resolved: tipc: hold a reference to nodes found by link name tipc_node_find_by_name() returns a node after dropping its RCU read lock without taking a reference. The LINK_SET, LINK_GET and LINK_RESET_STATS handlers then lock and access the node, racing with timer-driven cleanup of a down peer. Generic netlink serialization does not exclude the node timer. The following interleaving can leave a handler using a freed node: CPU 0: find the node under RCU and release the node read lock CPU 1: tipc_node_timeout() clears the links and unlinks the down node CPU 1: drop the list and timer references, queuing tipc_node_free() CPU 0: leave the RCU read-side critical section CPU 1: complete the grace period and free the node CPU 0: acquire the node lock through the stale pointer LINK_SET also uses the node's media address after releasing the node lock, when passing queued packets to tipc_bearer_xmit(). KASAN on v7.3-rc5 reported: BUG: KASAN: slab-use-after-free in _raw_read_lock_bh Write of size 4 at addr ffff88807e06f008 by task poc/92 Call Trace: _raw_read_lock_bh kernel/locking/spinlock.c:287 tipc_nl_node_set_link net/tipc/node.c:2475 genl_family_rcv_msg_doit net/netlink/genetlink.c:1114 genl_rcv_msg net/netlink/genetlink.c:1209 netlink_rcv_skb net/netlink/af_netlink.c:2575 Allocated by task 0: tipc_node_create net/tipc/node.c:539 tipc_node_check_dest net/tipc/node.c:1196 tipc_disc_rcv net/tipc/discover.c:252 Freed by task 92:","evidence":"cve:CVE-2026-99053","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99053","aliases":["CVE-2026-99053"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attacker-controlled selector is TIPC_NLA_LINK_NAME in a local NETLINK_GENERIC TIPC_NL_LINK_GET request, dispatched to tipc_nl_node_get_link() and patched tipc_node_find_by_name(). Remote packets can create or down the peer but cannot invoke this handler, so one remote actor cannot trigger the UAF.\nAC:L - The same local attacker can create TIPC peers in user/network namespaces, stop one so node_lost_contact() sets delete_at, and flood LINK_GET while tipc_node_timeout() performs cleanup. Both sides of this repeatable race are attacker-controlled, and the submitted PoC reached the KASAN UAF.\nPR:L - TIPC_NL_LINK_GET is registered without an administrative permission flag and reaches tipc_nl_node_get_link() for any local netlink caller. Setup mutators use GENL_UNS_ADMIN_PERM and the family has netnsok=true, allowing an unprivileged user to obtain the necessary namespace-local rights.\nUI:N - The attacker can create and stop its own TIPC peer and issue the racing TIPC_NL_LINK_GET requests without any victim action.\nS:U - The stale pointer from tipc_node_find_by_name() corrupts host-kernel tipc_node and tipc_link slab objects; no VM, IOMMU, or other security-authority boundary is crossed.\nC:H - TIPC_NL_LINK_GET follows a reclaimed node->links[bearer_id].link into __tipc_nl_add_link(), which copies link names, properties, and statistics into the attacker's netlink reply. Heap grooming can therefore turn the stale node into an arbitrary kernel-read primitive.\nI:H - _raw_read_lock_bh() already performs the reported four-byte write to freed node->lock. With a reclaimed links pointer, TIPC_NL_LINK_RESET_STATS reaches tipc_link_reset_stats(), whose memset() provides an attacker-directed kernel write suitable for further corruption or control-flow hijacking.\nA:H - The observed slab use-after-free occurs while tipc_nl_node_set_link() locks the freed node; corrupted lock state or the subsequent stale node/link dereferences can cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"b60259d4047fbb735476c729dcf9306a038b6110","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"f17e70206a1e763fcca2578a8db3c4eed0f843a9","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"1428c5f1d346a2e1ac9156713975a72246957009","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"3c3b308ee6e25729a6cf09b69cdd0e093220d40b","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"17e73bae400f6a434dc006e3bee92c94cf781954","versionType":"git"}],"programFiles":["net/tipc/node.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.19"},{"status":"unaffected","version":"0","lessThan":"4.19","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/tipc/node.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:13.569Z","provider":"cve","references":["https://git.kernel.org/stable/c/b60259d4047fbb735476c729dcf9306a038b6110","https://git.kernel.org/stable/c/f17e70206a1e763fcca2578a8db3c4eed0f843a9","https://git.kernel.org/stable/c/1428c5f1d346a2e1ac9156713975a72246957009","https://git.kernel.org/stable/c/3c3b308ee6e25729a6cf09b69cdd0e093220d40b","https://git.kernel.org/stable/c/17e73bae400f6a434dc006e3bee92c94cf781954"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:13.569Z"}}},"related_cves":[{"value":"CVE-2026-99053","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d2f2bb20-4ee7-4b38-a413-15323d2f6e2c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99053","advisory_id":"d2f2bb20-4ee7-4b38-a413-15323d2f6e2c","event_types":["advisory"],"published_at":"2026-10-25T16:10:47.275888+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:35.462+00:00","detail_url":"/advisories/advisory%3Ad2f2bb20-4ee7-4b38-a413-15323d2f6e2c","group":{"id":"advisory:d2f2bb20-4ee7-4b38-a413-15323d2f6e2c","revision":1,"primary_event_id":55742,"change":"published","superseded_by":[],"changed":{"id":55742,"cve_ids":["CVE-2026-99053"],"payload":{"kind":"advisory","title":"tipc: hold a reference to nodes found by link name","summary":"In the Linux kernel, the following vulnerability has been resolved: tipc: hold a reference to nodes found by link name tipc_node_find_by_name() returns a node after dropping its RCU read lock without taking a reference. The LINK_SET, LINK_GET and LINK_RESET_STATS handlers then lock and access the node, racing with timer-driven cleanup of a down peer. Generic netlink serialization does not exclude the node timer. The following interleaving can leave a handler using a freed node: CPU 0: find the node under RCU and release the node read lock CPU 1: tipc_node_timeout() clears the links and unlinks the down node CPU 1: drop the list and timer references, queuing tipc_node_free() CPU 0: leave the RCU read-side critical section CPU 1: complete the grace period and free the node CPU 0: acquire the node lock through the stale pointer LINK_SET also uses the node's media address after releasing the node lock, when passing queued packets to tipc_bearer_xmit(). KASAN on v7.3-rc5 reported: BUG: KASAN: slab-use-after-free in _raw_read_lock_bh Write of size 4 at addr ffff88807e06f008 by task poc/92 Call Trace: _raw_read_lock_bh kernel/locking/spinlock.c:287 tipc_nl_node_set_link net/tipc/node.c:2475 genl_family_rcv_msg_doit net/netlink/genetlink.c:1114 genl_rcv_msg net/netlink/genetlink.c:1209 netlink_rcv_skb net/netlink/af_netlink.c:2575 Allocated by task 0: tipc_node_create net/tipc/node.c:539 tipc_node_check_dest net/tipc/node.c:1196 tipc_disc_rcv net/tipc/discover.c:252 Freed by task 92:","evidence":"cve:CVE-2026-99053","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99053","aliases":["CVE-2026-99053"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attacker-controlled selector is TIPC_NLA_LINK_NAME in a local NETLINK_GENERIC TIPC_NL_LINK_GET request, dispatched to tipc_nl_node_get_link() and patched tipc_node_find_by_name(). Remote packets can create or down the peer but cannot invoke this handler, so one remote actor cannot trigger the UAF.\nAC:L - The same local attacker can create TIPC peers in user/network namespaces, stop one so node_lost_contact() sets delete_at, and flood LINK_GET while tipc_node_timeout() performs cleanup. Both sides of this repeatable race are attacker-controlled, and the submitted PoC reached the KASAN UAF.\nPR:L - TIPC_NL_LINK_GET is registered without an administrative permission flag and reaches tipc_nl_node_get_link() for any local netlink caller. Setup mutators use GENL_UNS_ADMIN_PERM and the family has netnsok=true, allowing an unprivileged user to obtain the necessary namespace-local rights.\nUI:N - The attacker can create and stop its own TIPC peer and issue the racing TIPC_NL_LINK_GET requests without any victim action.\nS:U - The stale pointer from tipc_node_find_by_name() corrupts host-kernel tipc_node and tipc_link slab objects; no VM, IOMMU, or other security-authority boundary is crossed.\nC:H - TIPC_NL_LINK_GET follows a reclaimed node->links[bearer_id].link into __tipc_nl_add_link(), which copies link names, properties, and statistics into the attacker's netlink reply. Heap grooming can therefore turn the stale node into an arbitrary kernel-read primitive.\nI:H - _raw_read_lock_bh() already performs the reported four-byte write to freed node->lock. With a reclaimed links pointer, TIPC_NL_LINK_RESET_STATS reaches tipc_link_reset_stats(), whose memset() provides an attacker-directed kernel write suitable for further corruption or control-flow hijacking.\nA:H - The observed slab use-after-free occurs while tipc_nl_node_set_link() locks the freed node; corrupted lock state or the subsequent stale node/link dereferences can cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"b60259d4047fbb735476c729dcf9306a038b6110","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"f17e70206a1e763fcca2578a8db3c4eed0f843a9","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"1428c5f1d346a2e1ac9156713975a72246957009","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"3c3b308ee6e25729a6cf09b69cdd0e093220d40b","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"17e73bae400f6a434dc006e3bee92c94cf781954","versionType":"git"}],"programFiles":["net/tipc/node.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.19"},{"status":"unaffected","version":"0","lessThan":"4.19","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/tipc/node.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:13.569Z","provider":"cve","references":["https://git.kernel.org/stable/c/b60259d4047fbb735476c729dcf9306a038b6110","https://git.kernel.org/stable/c/f17e70206a1e763fcca2578a8db3c4eed0f843a9","https://git.kernel.org/stable/c/1428c5f1d346a2e1ac9156713975a72246957009","https://git.kernel.org/stable/c/3c3b308ee6e25729a6cf09b69cdd0e093220d40b","https://git.kernel.org/stable/c/17e73bae400f6a434dc006e3bee92c94cf781954"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:13.569Z"}}},"related_cves":[{"value":"CVE-2026-99053","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d2f2bb20-4ee7-4b38-a413-15323d2f6e2c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99053","advisory_id":"d2f2bb20-4ee7-4b38-a413-15323d2f6e2c","event_types":["advisory"],"published_at":"2026-10-25T16:10:47.275888+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:35.462+00:00","detail_url":"/events/55742"},"members":[{"id":55742,"cve_ids":["CVE-2026-99053"],"payload":{"kind":"advisory","title":"tipc: hold a reference to nodes found by link name","summary":"In the Linux kernel, the following vulnerability has been resolved: tipc: hold a reference to nodes found by link name tipc_node_find_by_name() returns a node after dropping its RCU read lock without taking a reference. The LINK_SET, LINK_GET and LINK_RESET_STATS handlers then lock and access the node, racing with timer-driven cleanup of a down peer. Generic netlink serialization does not exclude the node timer. The following interleaving can leave a handler using a freed node: CPU 0: find the node under RCU and release the node read lock CPU 1: tipc_node_timeout() clears the links and unlinks the down node CPU 1: drop the list and timer references, queuing tipc_node_free() CPU 0: leave the RCU read-side critical section CPU 1: complete the grace period and free the node CPU 0: acquire the node lock through the stale pointer LINK_SET also uses the node's media address after releasing the node lock, when passing queued packets to tipc_bearer_xmit(). KASAN on v7.3-rc5 reported: BUG: KASAN: slab-use-after-free in _raw_read_lock_bh Write of size 4 at addr ffff88807e06f008 by task poc/92 Call Trace: _raw_read_lock_bh kernel/locking/spinlock.c:287 tipc_nl_node_set_link net/tipc/node.c:2475 genl_family_rcv_msg_doit net/netlink/genetlink.c:1114 genl_rcv_msg net/netlink/genetlink.c:1209 netlink_rcv_skb net/netlink/af_netlink.c:2575 Allocated by task 0: tipc_node_create net/tipc/node.c:539 tipc_node_check_dest net/tipc/node.c:1196 tipc_disc_rcv net/tipc/discover.c:252 Freed by task 92:","evidence":"cve:CVE-2026-99053","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99053","aliases":["CVE-2026-99053"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attacker-controlled selector is TIPC_NLA_LINK_NAME in a local NETLINK_GENERIC TIPC_NL_LINK_GET request, dispatched to tipc_nl_node_get_link() and patched tipc_node_find_by_name(). Remote packets can create or down the peer but cannot invoke this handler, so one remote actor cannot trigger the UAF.\nAC:L - The same local attacker can create TIPC peers in user/network namespaces, stop one so node_lost_contact() sets delete_at, and flood LINK_GET while tipc_node_timeout() performs cleanup. Both sides of this repeatable race are attacker-controlled, and the submitted PoC reached the KASAN UAF.\nPR:L - TIPC_NL_LINK_GET is registered without an administrative permission flag and reaches tipc_nl_node_get_link() for any local netlink caller. Setup mutators use GENL_UNS_ADMIN_PERM and the family has netnsok=true, allowing an unprivileged user to obtain the necessary namespace-local rights.\nUI:N - The attacker can create and stop its own TIPC peer and issue the racing TIPC_NL_LINK_GET requests without any victim action.\nS:U - The stale pointer from tipc_node_find_by_name() corrupts host-kernel tipc_node and tipc_link slab objects; no VM, IOMMU, or other security-authority boundary is crossed.\nC:H - TIPC_NL_LINK_GET follows a reclaimed node->links[bearer_id].link into __tipc_nl_add_link(), which copies link names, properties, and statistics into the attacker's netlink reply. Heap grooming can therefore turn the stale node into an arbitrary kernel-read primitive.\nI:H - _raw_read_lock_bh() already performs the reported four-byte write to freed node->lock. With a reclaimed links pointer, TIPC_NL_LINK_RESET_STATS reaches tipc_link_reset_stats(), whose memset() provides an attacker-directed kernel write suitable for further corruption or control-flow hijacking.\nA:H - The observed slab use-after-free occurs while tipc_nl_node_set_link() locks the freed node; corrupted lock state or the subsequent stale node/link dereferences can cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"b60259d4047fbb735476c729dcf9306a038b6110","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"f17e70206a1e763fcca2578a8db3c4eed0f843a9","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"1428c5f1d346a2e1ac9156713975a72246957009","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"3c3b308ee6e25729a6cf09b69cdd0e093220d40b","versionType":"git"},{"status":"affected","version":"6a939f365bdb03a74b4617bdb4402fc08da088b9","lessThan":"17e73bae400f6a434dc006e3bee92c94cf781954","versionType":"git"}],"programFiles":["net/tipc/node.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.19"},{"status":"unaffected","version":"0","lessThan":"4.19","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/tipc/node.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:13.569Z","provider":"cve","references":["https://git.kernel.org/stable/c/b60259d4047fbb735476c729dcf9306a038b6110","https://git.kernel.org/stable/c/f17e70206a1e763fcca2578a8db3c4eed0f843a9","https://git.kernel.org/stable/c/1428c5f1d346a2e1ac9156713975a72246957009","https://git.kernel.org/stable/c/3c3b308ee6e25729a6cf09b69cdd0e093220d40b","https://git.kernel.org/stable/c/17e73bae400f6a434dc006e3bee92c94cf781954"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:13.569Z"}}},"related_cves":[{"value":"CVE-2026-99053","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d2f2bb20-4ee7-4b38-a413-15323d2f6e2c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99053","advisory_id":"d2f2bb20-4ee7-4b38-a413-15323d2f6e2c","event_types":["advisory"],"published_at":"2026-10-25T16:10:47.275888+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:35.462+00:00","detail_url":"/events/55742"}]}},{"id":56217,"cve_ids":["CVE-2026-99051"],"payload":{"kind":"advisory","title":"fsverity: RCU-delay the freeing of struct fsverity_info","summary":"In the Linux kernel, the following vulnerability has been resolved: fsverity: RCU-delay the freeing of struct fsverity_info __fsverity_get_info() calls rhashtable_lookup_fast(), which just uses rcu_read_lock() and doesn't directly synchronize with fsverity_remove_info(). For the same inode this isn't a problem: its fsverity_info is removed only at inode eviction time or upon failure to enable verity, when the inode no longer needs its fsverity_info and it will no longer be accessed via that inode. However, this is broken and can cause a use-after-free for concurrent __fsverity_get_info() for *different* inodes. Those rely on following fsverity_info::rhash_head in the rhashtable under rcu_read_lock() only. They also use fsverity_info::inode to do the key comparison. Fix this by RCU-delaying the freeing of 'struct fsverity_info' after it's been removed from the rhashtable.","evidence":"cve:CVE-2026-99051","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99051","aliases":["CVE-2026-99051"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `ioctl(FS_IOC_MEASURE_VERITY)` reaches `fsverity_ioctl_measure()` and `fsverity_get_info()`, while `unlinkat()`/`close()` of another fs-verity file reaches `clear_inode()`, `fsverity_cleanup_inode()`, and patched `fsverity_remove_info()`; these are local syscall paths, not wire data.\nAC:L - An attacker can enable many owned files to populate colliding rhashtable chains, then loop measurements of one inode while concurrently unlinking and closing the others; the attacker controls both lookup and freeing and can repeat the race.\nPR:L - `fsverity_ioctl_enable()` checks only `file_permission(filp, MAY_WRITE)`, `FMODE_READ`, and a writable mount, with no capability check; lookup and eviction require only ordinary access to attacker-owned files on btrfs or verity-enabled ext4/f2fs.\nUI:N - The attacker can create, enable, measure, unlink, and close all participating files using their own processes, without another user mounting media or taking any action.\nS:U - The dangling object belongs to the host kernel's `fsverity_info_hash` and `fsverity_info_cachep`; corrupting it affects the same kernel security authority and crosses no VM, IOMMU, or hypervisor boundary.\nC:H - `fsverity_remove_info()` frees the slab while `__rhashtable_lookup()` still reads `inode` and `rhash_head.next`; after cache reuse, a misdirected lookup is consumed by `fsverity_ioctl_measure()`, which dereferences `tree_params` and copies `file_digest` to userspace.\nI:H - File-read consumers pass the lookup result to `fsverity_verify_blocks()`, whose `clear_bit()` and `set_bit()` write through `vi->hash_block_verified`; attacker-groomed reuse of the freed object can therefore turn the UAF into arbitrary kernel-memory corruption.\nA:H - `kmem_cache_free()` permits allocator metadata to replace the freed `rhash_head.next` while the rhashtable loop still follows `pos->next`, which can oops or panic the kernel; repeated measure-and-evict cycles can retrigger it."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"f77f281b61183a5c0b87e6a4d101c70bd32c1c79","lessThan":"fa84f091a8e7fc46fd29834496fab9739dd4c8dc","versionType":"git"},{"status":"affected","version":"f77f281b61183a5c0b87e6a4d101c70bd32c1c79","lessThan":"e58c3805ed325fe2d4ae2dd467c0486cc860b733","versionType":"git"}],"programFiles":["fs/verity/fsverity_private.h","fs/verity/open.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"7.0"},{"status":"unaffected","version":"0","lessThan":"7.0","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/verity/fsverity_private.h","fs/verity/open.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:12.469Z","provider":"cve","references":["https://git.kernel.org/stable/c/fa84f091a8e7fc46fd29834496fab9739dd4c8dc","https://git.kernel.org/stable/c/e58c3805ed325fe2d4ae2dd467c0486cc860b733"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:12.469Z"}}},"related_cves":[{"value":"CVE-2026-99051","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ccc37853-1de7-4f9b-ab2f-2194558b782c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99051","advisory_id":"ccc37853-1de7-4f9b-ab2f-2194558b782c","event_types":["advisory"],"published_at":"2026-10-25T16:10:46.579895+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:30.37+00:00","detail_url":"/advisories/advisory%3Accc37853-1de7-4f9b-ab2f-2194558b782c","group":{"id":"advisory:ccc37853-1de7-4f9b-ab2f-2194558b782c","revision":1,"primary_event_id":55741,"change":"published","superseded_by":[],"changed":{"id":55741,"cve_ids":["CVE-2026-99051"],"payload":{"kind":"advisory","title":"fsverity: RCU-delay the freeing of struct fsverity_info","summary":"In the Linux kernel, the following vulnerability has been resolved: fsverity: RCU-delay the freeing of struct fsverity_info __fsverity_get_info() calls rhashtable_lookup_fast(), which just uses rcu_read_lock() and doesn't directly synchronize with fsverity_remove_info(). For the same inode this isn't a problem: its fsverity_info is removed only at inode eviction time or upon failure to enable verity, when the inode no longer needs its fsverity_info and it will no longer be accessed via that inode. However, this is broken and can cause a use-after-free for concurrent __fsverity_get_info() for *different* inodes. Those rely on following fsverity_info::rhash_head in the rhashtable under rcu_read_lock() only. They also use fsverity_info::inode to do the key comparison. Fix this by RCU-delaying the freeing of 'struct fsverity_info' after it's been removed from the rhashtable.","evidence":"cve:CVE-2026-99051","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99051","aliases":["CVE-2026-99051"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `ioctl(FS_IOC_MEASURE_VERITY)` reaches `fsverity_ioctl_measure()` and `fsverity_get_info()`, while `unlinkat()`/`close()` of another fs-verity file reaches `clear_inode()`, `fsverity_cleanup_inode()`, and patched `fsverity_remove_info()`; these are local syscall paths, not wire data.\nAC:L - An attacker can enable many owned files to populate colliding rhashtable chains, then loop measurements of one inode while concurrently unlinking and closing the others; the attacker controls both lookup and freeing and can repeat the race.\nPR:L - `fsverity_ioctl_enable()` checks only `file_permission(filp, MAY_WRITE)`, `FMODE_READ`, and a writable mount, with no capability check; lookup and eviction require only ordinary access to attacker-owned files on btrfs or verity-enabled ext4/f2fs.\nUI:N - The attacker can create, enable, measure, unlink, and close all participating files using their own processes, without another user mounting media or taking any action.\nS:U - The dangling object belongs to the host kernel's `fsverity_info_hash` and `fsverity_info_cachep`; corrupting it affects the same kernel security authority and crosses no VM, IOMMU, or hypervisor boundary.\nC:H - `fsverity_remove_info()` frees the slab while `__rhashtable_lookup()` still reads `inode` and `rhash_head.next`; after cache reuse, a misdirected lookup is consumed by `fsverity_ioctl_measure()`, which dereferences `tree_params` and copies `file_digest` to userspace.\nI:H - File-read consumers pass the lookup result to `fsverity_verify_blocks()`, whose `clear_bit()` and `set_bit()` write through `vi->hash_block_verified`; attacker-groomed reuse of the freed object can therefore turn the UAF into arbitrary kernel-memory corruption.\nA:H - `kmem_cache_free()` permits allocator metadata to replace the freed `rhash_head.next` while the rhashtable loop still follows `pos->next`, which can oops or panic the kernel; repeated measure-and-evict cycles can retrigger it."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"f77f281b61183a5c0b87e6a4d101c70bd32c1c79","lessThan":"fa84f091a8e7fc46fd29834496fab9739dd4c8dc","versionType":"git"},{"status":"affected","version":"f77f281b61183a5c0b87e6a4d101c70bd32c1c79","lessThan":"e58c3805ed325fe2d4ae2dd467c0486cc860b733","versionType":"git"}],"programFiles":["fs/verity/fsverity_private.h","fs/verity/open.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"7.0"},{"status":"unaffected","version":"0","lessThan":"7.0","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/verity/fsverity_private.h","fs/verity/open.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:12.469Z","provider":"cve","references":["https://git.kernel.org/stable/c/fa84f091a8e7fc46fd29834496fab9739dd4c8dc","https://git.kernel.org/stable/c/e58c3805ed325fe2d4ae2dd467c0486cc860b733"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:12.469Z"}}},"related_cves":[{"value":"CVE-2026-99051","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ccc37853-1de7-4f9b-ab2f-2194558b782c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99051","advisory_id":"ccc37853-1de7-4f9b-ab2f-2194558b782c","event_types":["advisory"],"published_at":"2026-10-25T16:10:46.579895+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:30.37+00:00","detail_url":"/events/55741"},"members":[{"id":55741,"cve_ids":["CVE-2026-99051"],"payload":{"kind":"advisory","title":"fsverity: RCU-delay the freeing of struct fsverity_info","summary":"In the Linux kernel, the following vulnerability has been resolved: fsverity: RCU-delay the freeing of struct fsverity_info __fsverity_get_info() calls rhashtable_lookup_fast(), which just uses rcu_read_lock() and doesn't directly synchronize with fsverity_remove_info(). For the same inode this isn't a problem: its fsverity_info is removed only at inode eviction time or upon failure to enable verity, when the inode no longer needs its fsverity_info and it will no longer be accessed via that inode. However, this is broken and can cause a use-after-free for concurrent __fsverity_get_info() for *different* inodes. Those rely on following fsverity_info::rhash_head in the rhashtable under rcu_read_lock() only. They also use fsverity_info::inode to do the key comparison. Fix this by RCU-delaying the freeing of 'struct fsverity_info' after it's been removed from the rhashtable.","evidence":"cve:CVE-2026-99051","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99051","aliases":["CVE-2026-99051"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `ioctl(FS_IOC_MEASURE_VERITY)` reaches `fsverity_ioctl_measure()` and `fsverity_get_info()`, while `unlinkat()`/`close()` of another fs-verity file reaches `clear_inode()`, `fsverity_cleanup_inode()`, and patched `fsverity_remove_info()`; these are local syscall paths, not wire data.\nAC:L - An attacker can enable many owned files to populate colliding rhashtable chains, then loop measurements of one inode while concurrently unlinking and closing the others; the attacker controls both lookup and freeing and can repeat the race.\nPR:L - `fsverity_ioctl_enable()` checks only `file_permission(filp, MAY_WRITE)`, `FMODE_READ`, and a writable mount, with no capability check; lookup and eviction require only ordinary access to attacker-owned files on btrfs or verity-enabled ext4/f2fs.\nUI:N - The attacker can create, enable, measure, unlink, and close all participating files using their own processes, without another user mounting media or taking any action.\nS:U - The dangling object belongs to the host kernel's `fsverity_info_hash` and `fsverity_info_cachep`; corrupting it affects the same kernel security authority and crosses no VM, IOMMU, or hypervisor boundary.\nC:H - `fsverity_remove_info()` frees the slab while `__rhashtable_lookup()` still reads `inode` and `rhash_head.next`; after cache reuse, a misdirected lookup is consumed by `fsverity_ioctl_measure()`, which dereferences `tree_params` and copies `file_digest` to userspace.\nI:H - File-read consumers pass the lookup result to `fsverity_verify_blocks()`, whose `clear_bit()` and `set_bit()` write through `vi->hash_block_verified`; attacker-groomed reuse of the freed object can therefore turn the UAF into arbitrary kernel-memory corruption.\nA:H - `kmem_cache_free()` permits allocator metadata to replace the freed `rhash_head.next` while the rhashtable loop still follows `pos->next`, which can oops or panic the kernel; repeated measure-and-evict cycles can retrigger it."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"f77f281b61183a5c0b87e6a4d101c70bd32c1c79","lessThan":"fa84f091a8e7fc46fd29834496fab9739dd4c8dc","versionType":"git"},{"status":"affected","version":"f77f281b61183a5c0b87e6a4d101c70bd32c1c79","lessThan":"e58c3805ed325fe2d4ae2dd467c0486cc860b733","versionType":"git"}],"programFiles":["fs/verity/fsverity_private.h","fs/verity/open.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"7.0"},{"status":"unaffected","version":"0","lessThan":"7.0","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/verity/fsverity_private.h","fs/verity/open.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:12.469Z","provider":"cve","references":["https://git.kernel.org/stable/c/fa84f091a8e7fc46fd29834496fab9739dd4c8dc","https://git.kernel.org/stable/c/e58c3805ed325fe2d4ae2dd467c0486cc860b733"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:12.469Z"}}},"related_cves":[{"value":"CVE-2026-99051","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ccc37853-1de7-4f9b-ab2f-2194558b782c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99051","advisory_id":"ccc37853-1de7-4f9b-ab2f-2194558b782c","event_types":["advisory"],"published_at":"2026-10-25T16:10:46.579895+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:30.37+00:00","detail_url":"/events/55741"}]}},{"id":56216,"cve_ids":["CVE-2026-99042"],"payload":{"kind":"advisory","title":"io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6","summary":"In the Linux kernel, the following vulnerability has been resolved: io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6 io_connect_bpf_populate() fills connect.port and connect.v6_addr for AF_INET6 only when addr_len >= sizeof(struct sockaddr_in6), i.e. 28 bytes. The IPv6 connect paths accept SIN6_LEN_RFC2133 (24 bytes), which already holds sin6_port and sin6_addr. io_connect() passes addr_len to the socket layer unchanged. At addr_len 24 the filter sees family AF_INET6 with port and address zero, while the kernel connects to the real destination. A filter that denies an IPv6 port or address is bypassed. Denying connect.port == P rejects [::1]:P with -EACCES at addr_len 28 but connects at addr_len 24. Use SIN6_LEN_RFC2133 as the threshold. sin6_scope_id stays zero when absent. The threshold mismatch was found by an AI coding assistant (Claude Code) comparing this hook against the net/ipv6 length checks on my instructions; it also drafted the reproducer and this patch. I verified the bypass and the fix in a VM on 7.3-rc6 and that 7.2 has the same code.","evidence":"cve:CVE-2026-99042","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99042","aliases":["CVE-2026-99042"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N"},"scenarios":[{"lang":"en","value":"AV:L - An attacker reaches the patched io_connect_bpf_populate() by locally submitting IORING_OP_CONNECT through io_uring_enter(), with sqe->addr2 supplying the malicious 24-byte length. No network packet carries the value creating the mismatch.\nAC:L - Against a CONNECT filter denying an IPv6 port or address, addr2=24 deterministically makes io_connect_bpf_populate() expose zero port/address while tcp_v6_connect() accepts and uses the real fields; no race or uncontrolled condition is involved.\nPR:L - No capability check exists in io_uring_enter(), io_connect_prep(), or io_connect(), and AF_INET6 SOCK_STREAM creation avoids inet6_create()'s CAP_NET_RAW check. An ordinary confined process with access to the filtered ring can trigger the bypass.\nUI:N - The confined process prepares and submits the 24-byte sockaddr itself, and io_connect_prep() copies it during io_uring_enter(); no other user must mount, open, approve, or otherwise act.\nS:C - The false port/address view escapes the io_uring BPF CONNECT sandbox: __io_uring_run_bpf_filters() allows an operation that an inherited or ring-level filter intended to deny, reaching network resources outside that policy scope.\nC:H - After the filter sees :: and port 0, tcp_v6_connect() uses sin6_addr and sin6_port from the same 24 bytes; the confined process can establish a full socket and read responses from IPv6 services the CONNECT filter explicitly made inaccessible.\nI:H - tcp_v6_connect() stores the hidden destination in sk_v6_daddr and inet_dport and establishes the denied socket, enabling arbitrary application data and requests to be sent to IPv6 services and ports prohibited by the sandbox policy.\nA:N - The bug only substitutes zero values in the filter context; move_addr_to_kernel() safely copies 24 bytes and the IPv6 socket layer accepts that size. It introduces no corruption, out-of-bounds access, oops, hang, or resource exhaustion."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"899bea8248cee35d54760a5e7d61a76af8e64411","lessThan":"596a955d2d01b7e29d9fed60ebcf7c4ba518b8e5","versionType":"git"},{"status":"affected","version":"899bea8248cee35d54760a5e7d61a76af8e64411","lessThan":"aa5d5f8e502318e783545ba5d04bb40130b83e20","versionType":"git"}],"programFiles":["io_uring/net.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"7.2"},{"status":"unaffected","version":"0","lessThan":"7.2","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["io_uring/net.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:09.161Z","provider":"cve","references":["https://git.kernel.org/stable/c/596a955d2d01b7e29d9fed60ebcf7c4ba518b8e5","https://git.kernel.org/stable/c/aa5d5f8e502318e783545ba5d04bb40130b83e20"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:09.161Z"}}},"related_cves":[{"value":"CVE-2026-99042","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:0f620a84-245f-483a-92be-bb7d55273026","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99042","advisory_id":"0f620a84-245f-483a-92be-bb7d55273026","event_types":["advisory"],"published_at":"2026-10-25T16:10:45.838757+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:01.804+00:00","detail_url":"/advisories/advisory%3A0f620a84-245f-483a-92be-bb7d55273026","group":{"id":"advisory:0f620a84-245f-483a-92be-bb7d55273026","revision":1,"primary_event_id":55740,"change":"published","superseded_by":[],"changed":{"id":55740,"cve_ids":["CVE-2026-99042"],"payload":{"kind":"advisory","title":"io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6","summary":"In the Linux kernel, the following vulnerability has been resolved: io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6 io_connect_bpf_populate() fills connect.port and connect.v6_addr for AF_INET6 only when addr_len >= sizeof(struct sockaddr_in6), i.e. 28 bytes. The IPv6 connect paths accept SIN6_LEN_RFC2133 (24 bytes), which already holds sin6_port and sin6_addr. io_connect() passes addr_len to the socket layer unchanged. At addr_len 24 the filter sees family AF_INET6 with port and address zero, while the kernel connects to the real destination. A filter that denies an IPv6 port or address is bypassed. Denying connect.port == P rejects [::1]:P with -EACCES at addr_len 28 but connects at addr_len 24. Use SIN6_LEN_RFC2133 as the threshold. sin6_scope_id stays zero when absent. The threshold mismatch was found by an AI coding assistant (Claude Code) comparing this hook against the net/ipv6 length checks on my instructions; it also drafted the reproducer and this patch. I verified the bypass and the fix in a VM on 7.3-rc6 and that 7.2 has the same code.","evidence":"cve:CVE-2026-99042","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99042","aliases":["CVE-2026-99042"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N"},"scenarios":[{"lang":"en","value":"AV:L - An attacker reaches the patched io_connect_bpf_populate() by locally submitting IORING_OP_CONNECT through io_uring_enter(), with sqe->addr2 supplying the malicious 24-byte length. No network packet carries the value creating the mismatch.\nAC:L - Against a CONNECT filter denying an IPv6 port or address, addr2=24 deterministically makes io_connect_bpf_populate() expose zero port/address while tcp_v6_connect() accepts and uses the real fields; no race or uncontrolled condition is involved.\nPR:L - No capability check exists in io_uring_enter(), io_connect_prep(), or io_connect(), and AF_INET6 SOCK_STREAM creation avoids inet6_create()'s CAP_NET_RAW check. An ordinary confined process with access to the filtered ring can trigger the bypass.\nUI:N - The confined process prepares and submits the 24-byte sockaddr itself, and io_connect_prep() copies it during io_uring_enter(); no other user must mount, open, approve, or otherwise act.\nS:C - The false port/address view escapes the io_uring BPF CONNECT sandbox: __io_uring_run_bpf_filters() allows an operation that an inherited or ring-level filter intended to deny, reaching network resources outside that policy scope.\nC:H - After the filter sees :: and port 0, tcp_v6_connect() uses sin6_addr and sin6_port from the same 24 bytes; the confined process can establish a full socket and read responses from IPv6 services the CONNECT filter explicitly made inaccessible.\nI:H - tcp_v6_connect() stores the hidden destination in sk_v6_daddr and inet_dport and establishes the denied socket, enabling arbitrary application data and requests to be sent to IPv6 services and ports prohibited by the sandbox policy.\nA:N - The bug only substitutes zero values in the filter context; move_addr_to_kernel() safely copies 24 bytes and the IPv6 socket layer accepts that size. It introduces no corruption, out-of-bounds access, oops, hang, or resource exhaustion."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"899bea8248cee35d54760a5e7d61a76af8e64411","lessThan":"596a955d2d01b7e29d9fed60ebcf7c4ba518b8e5","versionType":"git"},{"status":"affected","version":"899bea8248cee35d54760a5e7d61a76af8e64411","lessThan":"aa5d5f8e502318e783545ba5d04bb40130b83e20","versionType":"git"}],"programFiles":["io_uring/net.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"7.2"},{"status":"unaffected","version":"0","lessThan":"7.2","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["io_uring/net.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:09.161Z","provider":"cve","references":["https://git.kernel.org/stable/c/596a955d2d01b7e29d9fed60ebcf7c4ba518b8e5","https://git.kernel.org/stable/c/aa5d5f8e502318e783545ba5d04bb40130b83e20"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:09.161Z"}}},"related_cves":[{"value":"CVE-2026-99042","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:0f620a84-245f-483a-92be-bb7d55273026","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99042","advisory_id":"0f620a84-245f-483a-92be-bb7d55273026","event_types":["advisory"],"published_at":"2026-10-25T16:10:45.838757+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:01.804+00:00","detail_url":"/events/55740"},"members":[{"id":55740,"cve_ids":["CVE-2026-99042"],"payload":{"kind":"advisory","title":"io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6","summary":"In the Linux kernel, the following vulnerability has been resolved: io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6 io_connect_bpf_populate() fills connect.port and connect.v6_addr for AF_INET6 only when addr_len >= sizeof(struct sockaddr_in6), i.e. 28 bytes. The IPv6 connect paths accept SIN6_LEN_RFC2133 (24 bytes), which already holds sin6_port and sin6_addr. io_connect() passes addr_len to the socket layer unchanged. At addr_len 24 the filter sees family AF_INET6 with port and address zero, while the kernel connects to the real destination. A filter that denies an IPv6 port or address is bypassed. Denying connect.port == P rejects [::1]:P with -EACCES at addr_len 28 but connects at addr_len 24. Use SIN6_LEN_RFC2133 as the threshold. sin6_scope_id stays zero when absent. The threshold mismatch was found by an AI coding assistant (Claude Code) comparing this hook against the net/ipv6 length checks on my instructions; it also drafted the reproducer and this patch. I verified the bypass and the fix in a VM on 7.3-rc6 and that 7.2 has the same code.","evidence":"cve:CVE-2026-99042","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99042","aliases":["CVE-2026-99042"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":8.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N"},"scenarios":[{"lang":"en","value":"AV:L - An attacker reaches the patched io_connect_bpf_populate() by locally submitting IORING_OP_CONNECT through io_uring_enter(), with sqe->addr2 supplying the malicious 24-byte length. No network packet carries the value creating the mismatch.\nAC:L - Against a CONNECT filter denying an IPv6 port or address, addr2=24 deterministically makes io_connect_bpf_populate() expose zero port/address while tcp_v6_connect() accepts and uses the real fields; no race or uncontrolled condition is involved.\nPR:L - No capability check exists in io_uring_enter(), io_connect_prep(), or io_connect(), and AF_INET6 SOCK_STREAM creation avoids inet6_create()'s CAP_NET_RAW check. An ordinary confined process with access to the filtered ring can trigger the bypass.\nUI:N - The confined process prepares and submits the 24-byte sockaddr itself, and io_connect_prep() copies it during io_uring_enter(); no other user must mount, open, approve, or otherwise act.\nS:C - The false port/address view escapes the io_uring BPF CONNECT sandbox: __io_uring_run_bpf_filters() allows an operation that an inherited or ring-level filter intended to deny, reaching network resources outside that policy scope.\nC:H - After the filter sees :: and port 0, tcp_v6_connect() uses sin6_addr and sin6_port from the same 24 bytes; the confined process can establish a full socket and read responses from IPv6 services the CONNECT filter explicitly made inaccessible.\nI:H - tcp_v6_connect() stores the hidden destination in sk_v6_daddr and inet_dport and establishes the denied socket, enabling arbitrary application data and requests to be sent to IPv6 services and ports prohibited by the sandbox policy.\nA:N - The bug only substitutes zero values in the filter context; move_addr_to_kernel() safely copies 24 bytes and the IPv6 socket layer accepts that size. It introduces no corruption, out-of-bounds access, oops, hang, or resource exhaustion."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"899bea8248cee35d54760a5e7d61a76af8e64411","lessThan":"596a955d2d01b7e29d9fed60ebcf7c4ba518b8e5","versionType":"git"},{"status":"affected","version":"899bea8248cee35d54760a5e7d61a76af8e64411","lessThan":"aa5d5f8e502318e783545ba5d04bb40130b83e20","versionType":"git"}],"programFiles":["io_uring/net.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"7.2"},{"status":"unaffected","version":"0","lessThan":"7.2","versionType":"semver"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["io_uring/net.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:09.161Z","provider":"cve","references":["https://git.kernel.org/stable/c/596a955d2d01b7e29d9fed60ebcf7c4ba518b8e5","https://git.kernel.org/stable/c/aa5d5f8e502318e783545ba5d04bb40130b83e20"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:09.161Z"}}},"related_cves":[{"value":"CVE-2026-99042","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:0f620a84-245f-483a-92be-bb7d55273026","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99042","advisory_id":"0f620a84-245f-483a-92be-bb7d55273026","event_types":["advisory"],"published_at":"2026-10-25T16:10:45.838757+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:01.804+00:00","detail_url":"/events/55740"}]}},{"id":56215,"cve_ids":["CVE-2026-99046"],"payload":{"kind":"advisory","title":"gve: fix XSK buffer leak on error descriptor","summary":"In the Linux kernel, the following vulnerability has been resolved: gve: fix XSK buffer leak on error descriptor When the error bit is set in the RX completion descriptor, the buf_state and its attached buffer should be freed. In the case of AF_XDP ZC, the XSK buffer was not freed, leading to a leak. This issue was caught by LLM.","evidence":"cve:CVE-2026-99046","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99046","aliases":["CVE-2026-99046"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A malformed Ethernet/IP packet received by gVNIC produces a DQO completion whose rx_error field denotes an invalid packet; gve_intr_dqo() schedules gve_napi_poll_dqo(), which reaches the patched gve_rx_dqo() through gve_rx_poll_dqo().\nAC:L - With a DQO-RDA AF_XDP zero-copy queue active, the sender can repeatedly transmit packets classified by the device as invalid; gve_rx_dqo() then deterministically takes the rx_error branch without a race or memory-layout dependency.\nPR:N - The gve_rx_dqo() receive path performs no authentication or capability check; xsk_create()'s CAP_NET_RAW check and XDP attachment are victim-side service provisioning, while the remote sender needs only packet access.\nUI:N - After gve_reg_xsk_pool() activates the pool, gve_intr_dqo() and NAPI process each error completion automatically without any victim action.\nS:U - The leak affects the guest kernel's own GVE XSK pool and DQO receive queue; it neither bypasses an IOMMU nor crosses the guest/hypervisor boundary.\nC:N - The lost xdp_buff_xsk remains allocated but unreturned; the branch performs no out-of-bounds read or data return, and gve_alloc_buf_state() clears the stale pointer before reusing the state.\nI:N - In the vulnerable XSK case, gve_free_buffer() releases only page-pool state and the buf_state while leaving the XSK object allocated, causing resource loss without a dangling access, memory corruption, or unauthorized modification.\nA:H - Each error completion omits xsk_buff_free()/xp_free(), removing one frame from the fixed XSK pool; repetition makes xsk_buff_alloc() fail in gve_alloc_buffer(), prevents RX-buffer reposting, and can stop the bound receive queue until the pool or service is reset."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"06656aaa7e43ae62b673c2244d27099b8b94a70d","versionType":"git"},{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"889f763874855c575429f75946132a53c573aa14","versionType":"git"},{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e","versionType":"git"}],"programFiles":["drivers/net/ethernet/google/gve/gve_rx_dqo.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.17"},{"status":"unaffected","version":"0","lessThan":"6.17","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/google/gve/gve_rx_dqo.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:10.249Z","provider":"cve","references":["https://git.kernel.org/stable/c/06656aaa7e43ae62b673c2244d27099b8b94a70d","https://git.kernel.org/stable/c/889f763874855c575429f75946132a53c573aa14","https://git.kernel.org/stable/c/9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:10.249Z"}}},"related_cves":[{"value":"CVE-2026-99046","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2f8cedc6-1e52-4369-af28-14d3493cc3a1","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99046","advisory_id":"2f8cedc6-1e52-4369-af28-14d3493cc3a1","event_types":["advisory"],"published_at":"2026-10-25T16:10:45.161283+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:10.46+00:00","detail_url":"/advisories/advisory%3A2f8cedc6-1e52-4369-af28-14d3493cc3a1","group":{"id":"advisory:2f8cedc6-1e52-4369-af28-14d3493cc3a1","revision":1,"primary_event_id":55739,"change":"published","superseded_by":[],"changed":{"id":55739,"cve_ids":["CVE-2026-99046"],"payload":{"kind":"advisory","title":"gve: fix XSK buffer leak on error descriptor","summary":"In the Linux kernel, the following vulnerability has been resolved: gve: fix XSK buffer leak on error descriptor When the error bit is set in the RX completion descriptor, the buf_state and its attached buffer should be freed. In the case of AF_XDP ZC, the XSK buffer was not freed, leading to a leak. This issue was caught by LLM.","evidence":"cve:CVE-2026-99046","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99046","aliases":["CVE-2026-99046"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A malformed Ethernet/IP packet received by gVNIC produces a DQO completion whose rx_error field denotes an invalid packet; gve_intr_dqo() schedules gve_napi_poll_dqo(), which reaches the patched gve_rx_dqo() through gve_rx_poll_dqo().\nAC:L - With a DQO-RDA AF_XDP zero-copy queue active, the sender can repeatedly transmit packets classified by the device as invalid; gve_rx_dqo() then deterministically takes the rx_error branch without a race or memory-layout dependency.\nPR:N - The gve_rx_dqo() receive path performs no authentication or capability check; xsk_create()'s CAP_NET_RAW check and XDP attachment are victim-side service provisioning, while the remote sender needs only packet access.\nUI:N - After gve_reg_xsk_pool() activates the pool, gve_intr_dqo() and NAPI process each error completion automatically without any victim action.\nS:U - The leak affects the guest kernel's own GVE XSK pool and DQO receive queue; it neither bypasses an IOMMU nor crosses the guest/hypervisor boundary.\nC:N - The lost xdp_buff_xsk remains allocated but unreturned; the branch performs no out-of-bounds read or data return, and gve_alloc_buf_state() clears the stale pointer before reusing the state.\nI:N - In the vulnerable XSK case, gve_free_buffer() releases only page-pool state and the buf_state while leaving the XSK object allocated, causing resource loss without a dangling access, memory corruption, or unauthorized modification.\nA:H - Each error completion omits xsk_buff_free()/xp_free(), removing one frame from the fixed XSK pool; repetition makes xsk_buff_alloc() fail in gve_alloc_buffer(), prevents RX-buffer reposting, and can stop the bound receive queue until the pool or service is reset."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"06656aaa7e43ae62b673c2244d27099b8b94a70d","versionType":"git"},{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"889f763874855c575429f75946132a53c573aa14","versionType":"git"},{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e","versionType":"git"}],"programFiles":["drivers/net/ethernet/google/gve/gve_rx_dqo.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.17"},{"status":"unaffected","version":"0","lessThan":"6.17","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/google/gve/gve_rx_dqo.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:10.249Z","provider":"cve","references":["https://git.kernel.org/stable/c/06656aaa7e43ae62b673c2244d27099b8b94a70d","https://git.kernel.org/stable/c/889f763874855c575429f75946132a53c573aa14","https://git.kernel.org/stable/c/9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:10.249Z"}}},"related_cves":[{"value":"CVE-2026-99046","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2f8cedc6-1e52-4369-af28-14d3493cc3a1","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99046","advisory_id":"2f8cedc6-1e52-4369-af28-14d3493cc3a1","event_types":["advisory"],"published_at":"2026-10-25T16:10:45.161283+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:10.46+00:00","detail_url":"/events/55739"},"members":[{"id":55739,"cve_ids":["CVE-2026-99046"],"payload":{"kind":"advisory","title":"gve: fix XSK buffer leak on error descriptor","summary":"In the Linux kernel, the following vulnerability has been resolved: gve: fix XSK buffer leak on error descriptor When the error bit is set in the RX completion descriptor, the buf_state and its attached buffer should be freed. In the case of AF_XDP ZC, the XSK buffer was not freed, leading to a leak. This issue was caught by LLM.","evidence":"cve:CVE-2026-99046","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99046","aliases":["CVE-2026-99046"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"},"scenarios":[{"lang":"en","value":"AV:N - A malformed Ethernet/IP packet received by gVNIC produces a DQO completion whose rx_error field denotes an invalid packet; gve_intr_dqo() schedules gve_napi_poll_dqo(), which reaches the patched gve_rx_dqo() through gve_rx_poll_dqo().\nAC:L - With a DQO-RDA AF_XDP zero-copy queue active, the sender can repeatedly transmit packets classified by the device as invalid; gve_rx_dqo() then deterministically takes the rx_error branch without a race or memory-layout dependency.\nPR:N - The gve_rx_dqo() receive path performs no authentication or capability check; xsk_create()'s CAP_NET_RAW check and XDP attachment are victim-side service provisioning, while the remote sender needs only packet access.\nUI:N - After gve_reg_xsk_pool() activates the pool, gve_intr_dqo() and NAPI process each error completion automatically without any victim action.\nS:U - The leak affects the guest kernel's own GVE XSK pool and DQO receive queue; it neither bypasses an IOMMU nor crosses the guest/hypervisor boundary.\nC:N - The lost xdp_buff_xsk remains allocated but unreturned; the branch performs no out-of-bounds read or data return, and gve_alloc_buf_state() clears the stale pointer before reusing the state.\nI:N - In the vulnerable XSK case, gve_free_buffer() releases only page-pool state and the buf_state while leaving the XSK object allocated, causing resource loss without a dangling access, memory corruption, or unauthorized modification.\nA:H - Each error completion omits xsk_buff_free()/xp_free(), removing one frame from the fixed XSK pool; repetition makes xsk_buff_alloc() fail in gve_alloc_buffer(), prevents RX-buffer reposting, and can stop the bound receive queue until the pool or service is reset."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"06656aaa7e43ae62b673c2244d27099b8b94a70d","versionType":"git"},{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"889f763874855c575429f75946132a53c573aa14","versionType":"git"},{"status":"affected","version":"c1fffc5d66a7147d557736c2341a511e0896d9ff","lessThan":"9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e","versionType":"git"}],"programFiles":["drivers/net/ethernet/google/gve/gve_rx_dqo.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.17"},{"status":"unaffected","version":"0","lessThan":"6.17","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/net/ethernet/google/gve/gve_rx_dqo.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:10.249Z","provider":"cve","references":["https://git.kernel.org/stable/c/06656aaa7e43ae62b673c2244d27099b8b94a70d","https://git.kernel.org/stable/c/889f763874855c575429f75946132a53c573aa14","https://git.kernel.org/stable/c/9fed6a8ab8a5bacba2c709cb19d2dd6d2fa9112e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:10.249Z"}}},"related_cves":[{"value":"CVE-2026-99046","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2f8cedc6-1e52-4369-af28-14d3493cc3a1","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99046","advisory_id":"2f8cedc6-1e52-4369-af28-14d3493cc3a1","event_types":["advisory"],"published_at":"2026-10-25T16:10:45.161283+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:10.46+00:00","detail_url":"/events/55739"}]}},{"id":56214,"cve_ids":["CVE-2026-99050"],"payload":{"kind":"advisory","title":"gpio: mpsse: fix race when arming the IRQ poll worker","summary":"In the Linux kernel, the following vulnerability has been resolved: gpio: mpsse: fix race when arming the IRQ poll worker gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv->workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free. Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running. A worker armed after the disconnect walk would still be missed, so also set a new priv->dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core's raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared. This issue was found by an in-house static analysis tool.","evidence":"cve:CVE-2026-99050","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99050","aliases":["CVE-2026-99050"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process can race GPIO_V2_GET_LINE_IOCTL -> linereq_create() -> edge_detector_setup() -> request_threaded_irq() -> gpio_mpsse_irq_enable() against USBDEVFS_IOCTL/USBDEVFS_DISCONNECT -> usb_driver_release_interface() -> gpio_mpsse_disconnect(); no network input reaches the bug.\nAC:L - The attacker can issue the GPIO line-event request and USBFS unbind concurrently and repeat after rebinding; both sides of the schedule_work()-before-list_add() window are attacker-controlled.\nPR:L - Neither gpio_ioctl() nor the USBDEVFS_DISCONNECT path performs a capability check; the process only needs non-root DAC/ACL access to /dev/gpiochipN and writable access to the matching /dev/bus/usb node.\nUI:N - The same process submits the line-event and USB disconnect ioctls that create the race, so no action by another user is required.\nS:U - The freed mpsse_priv and orphaned gpio_mpsse_poll() worker are both in the host kernel; the path crosses no VM, IOMMU, or other security authority.\nC:H - gpio_mpsse_poll() continues through attacker-reclaimable mpsse_priv fields, including GPIO, IRQ-domain, USB-buffer, and interface pointers; the resulting UAF and write primitive can yield kernel code execution and unrestricted reads.\nI:H - gpio_mpsse_poll() locks and traverses priv->workers after priv is freed; reclaiming that allocation lets controlled list pointers reach list_del(), providing attacker-directed kernel writes and control-flow corruption.\nA:H - The orphaned gpio_mpsse_poll() can access freed mutex, spinlock, and list state, or use the NULL/stale priv->intf in MPSSE I/O, causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"472d900c8bcac301ae0e40fdca7db799bd989ff5","lessThan":"76390ac0bca7e5058b7482eb4d951c3bda5df812","versionType":"git"},{"status":"affected","version":"179ef1127d7a4f09f0e741fa9f30b8a8e7886271","lessThan":"c0071ee496e1228976c72b096f529503222708a0","versionType":"git"},{"status":"affected","version":"179ef1127d7a4f09f0e741fa9f30b8a8e7886271","lessThan":"7efa1a1953cd6b20b23a3524d5b4b81789c6ef25","versionType":"git"},{"status":"affected","version":"6.18.6","lessThan":"6.18.57","versionType":"semver"}],"programFiles":["drivers/gpio/gpio-mpsse.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.19"},{"status":"unaffected","version":"0","lessThan":"6.19","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpio/gpio-mpsse.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:11.370Z","provider":"cve","references":["https://git.kernel.org/stable/c/76390ac0bca7e5058b7482eb4d951c3bda5df812","https://git.kernel.org/stable/c/c0071ee496e1228976c72b096f529503222708a0","https://git.kernel.org/stable/c/7efa1a1953cd6b20b23a3524d5b4b81789c6ef25"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:11.370Z"}}},"related_cves":[{"value":"CVE-2026-99050","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6f17e31c-59d8-442f-b816-d29a96a8d568","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99050","advisory_id":"6f17e31c-59d8-442f-b816-d29a96a8d568","event_types":["advisory"],"published_at":"2026-10-25T16:10:44.502781+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:29.204+00:00","detail_url":"/advisories/advisory%3A6f17e31c-59d8-442f-b816-d29a96a8d568","group":{"id":"advisory:6f17e31c-59d8-442f-b816-d29a96a8d568","revision":1,"primary_event_id":55738,"change":"published","superseded_by":[],"changed":{"id":55738,"cve_ids":["CVE-2026-99050"],"payload":{"kind":"advisory","title":"gpio: mpsse: fix race when arming the IRQ poll worker","summary":"In the Linux kernel, the following vulnerability has been resolved: gpio: mpsse: fix race when arming the IRQ poll worker gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv->workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free. Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running. A worker armed after the disconnect walk would still be missed, so also set a new priv->dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core's raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared. This issue was found by an in-house static analysis tool.","evidence":"cve:CVE-2026-99050","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99050","aliases":["CVE-2026-99050"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process can race GPIO_V2_GET_LINE_IOCTL -> linereq_create() -> edge_detector_setup() -> request_threaded_irq() -> gpio_mpsse_irq_enable() against USBDEVFS_IOCTL/USBDEVFS_DISCONNECT -> usb_driver_release_interface() -> gpio_mpsse_disconnect(); no network input reaches the bug.\nAC:L - The attacker can issue the GPIO line-event request and USBFS unbind concurrently and repeat after rebinding; both sides of the schedule_work()-before-list_add() window are attacker-controlled.\nPR:L - Neither gpio_ioctl() nor the USBDEVFS_DISCONNECT path performs a capability check; the process only needs non-root DAC/ACL access to /dev/gpiochipN and writable access to the matching /dev/bus/usb node.\nUI:N - The same process submits the line-event and USB disconnect ioctls that create the race, so no action by another user is required.\nS:U - The freed mpsse_priv and orphaned gpio_mpsse_poll() worker are both in the host kernel; the path crosses no VM, IOMMU, or other security authority.\nC:H - gpio_mpsse_poll() continues through attacker-reclaimable mpsse_priv fields, including GPIO, IRQ-domain, USB-buffer, and interface pointers; the resulting UAF and write primitive can yield kernel code execution and unrestricted reads.\nI:H - gpio_mpsse_poll() locks and traverses priv->workers after priv is freed; reclaiming that allocation lets controlled list pointers reach list_del(), providing attacker-directed kernel writes and control-flow corruption.\nA:H - The orphaned gpio_mpsse_poll() can access freed mutex, spinlock, and list state, or use the NULL/stale priv->intf in MPSSE I/O, causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"472d900c8bcac301ae0e40fdca7db799bd989ff5","lessThan":"76390ac0bca7e5058b7482eb4d951c3bda5df812","versionType":"git"},{"status":"affected","version":"179ef1127d7a4f09f0e741fa9f30b8a8e7886271","lessThan":"c0071ee496e1228976c72b096f529503222708a0","versionType":"git"},{"status":"affected","version":"179ef1127d7a4f09f0e741fa9f30b8a8e7886271","lessThan":"7efa1a1953cd6b20b23a3524d5b4b81789c6ef25","versionType":"git"},{"status":"affected","version":"6.18.6","lessThan":"6.18.57","versionType":"semver"}],"programFiles":["drivers/gpio/gpio-mpsse.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.19"},{"status":"unaffected","version":"0","lessThan":"6.19","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpio/gpio-mpsse.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:11.370Z","provider":"cve","references":["https://git.kernel.org/stable/c/76390ac0bca7e5058b7482eb4d951c3bda5df812","https://git.kernel.org/stable/c/c0071ee496e1228976c72b096f529503222708a0","https://git.kernel.org/stable/c/7efa1a1953cd6b20b23a3524d5b4b81789c6ef25"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:11.370Z"}}},"related_cves":[{"value":"CVE-2026-99050","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6f17e31c-59d8-442f-b816-d29a96a8d568","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99050","advisory_id":"6f17e31c-59d8-442f-b816-d29a96a8d568","event_types":["advisory"],"published_at":"2026-10-25T16:10:44.502781+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:29.204+00:00","detail_url":"/events/55738"},"members":[{"id":55738,"cve_ids":["CVE-2026-99050"],"payload":{"kind":"advisory","title":"gpio: mpsse: fix race when arming the IRQ poll worker","summary":"In the Linux kernel, the following vulnerability has been resolved: gpio: mpsse: fix race when arming the IRQ poll worker gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv->workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free. Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guaranteed to be armed, and cancel_work_sync() handles it whether it is queued or running. A worker armed after the disconnect walk would still be missed, so also set a new priv->dying flag under irq_spin before the teardown walk, and check it in the same critical section, freeing it via kfree_rcu() instead when the device is going away, since kfree() would be called with the IRQ core's raw spinlock held and may sleep on PREEMPT_RT. schedule_work() is safe to call with irq_spin held, and the next probe gets a fresh mpsse_priv, so the flag never needs to be cleared. This issue was found by an in-house static analysis tool.","evidence":"cve:CVE-2026-99050","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99050","aliases":["CVE-2026-99050"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process can race GPIO_V2_GET_LINE_IOCTL -> linereq_create() -> edge_detector_setup() -> request_threaded_irq() -> gpio_mpsse_irq_enable() against USBDEVFS_IOCTL/USBDEVFS_DISCONNECT -> usb_driver_release_interface() -> gpio_mpsse_disconnect(); no network input reaches the bug.\nAC:L - The attacker can issue the GPIO line-event request and USBFS unbind concurrently and repeat after rebinding; both sides of the schedule_work()-before-list_add() window are attacker-controlled.\nPR:L - Neither gpio_ioctl() nor the USBDEVFS_DISCONNECT path performs a capability check; the process only needs non-root DAC/ACL access to /dev/gpiochipN and writable access to the matching /dev/bus/usb node.\nUI:N - The same process submits the line-event and USB disconnect ioctls that create the race, so no action by another user is required.\nS:U - The freed mpsse_priv and orphaned gpio_mpsse_poll() worker are both in the host kernel; the path crosses no VM, IOMMU, or other security authority.\nC:H - gpio_mpsse_poll() continues through attacker-reclaimable mpsse_priv fields, including GPIO, IRQ-domain, USB-buffer, and interface pointers; the resulting UAF and write primitive can yield kernel code execution and unrestricted reads.\nI:H - gpio_mpsse_poll() locks and traverses priv->workers after priv is freed; reclaiming that allocation lets controlled list pointers reach list_del(), providing attacker-directed kernel writes and control-flow corruption.\nA:H - The orphaned gpio_mpsse_poll() can access freed mutex, spinlock, and list state, or use the NULL/stale priv->intf in MPSSE I/O, causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"472d900c8bcac301ae0e40fdca7db799bd989ff5","lessThan":"76390ac0bca7e5058b7482eb4d951c3bda5df812","versionType":"git"},{"status":"affected","version":"179ef1127d7a4f09f0e741fa9f30b8a8e7886271","lessThan":"c0071ee496e1228976c72b096f529503222708a0","versionType":"git"},{"status":"affected","version":"179ef1127d7a4f09f0e741fa9f30b8a8e7886271","lessThan":"7efa1a1953cd6b20b23a3524d5b4b81789c6ef25","versionType":"git"},{"status":"affected","version":"6.18.6","lessThan":"6.18.57","versionType":"semver"}],"programFiles":["drivers/gpio/gpio-mpsse.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.19"},{"status":"unaffected","version":"0","lessThan":"6.19","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpio/gpio-mpsse.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:11.370Z","provider":"cve","references":["https://git.kernel.org/stable/c/76390ac0bca7e5058b7482eb4d951c3bda5df812","https://git.kernel.org/stable/c/c0071ee496e1228976c72b096f529503222708a0","https://git.kernel.org/stable/c/7efa1a1953cd6b20b23a3524d5b4b81789c6ef25"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:11.370Z"}}},"related_cves":[{"value":"CVE-2026-99050","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6f17e31c-59d8-442f-b816-d29a96a8d568","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99050","advisory_id":"6f17e31c-59d8-442f-b816-d29a96a8d568","event_types":["advisory"],"published_at":"2026-10-25T16:10:44.502781+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:22:29.204+00:00","detail_url":"/events/55738"}]}},{"id":56213,"cve_ids":["CVE-2026-99032"],"payload":{"kind":"advisory","title":"net/smc: protect clcsock lifetime in smc_getname","summary":"In the Linux kernel, the following vulnerability has been resolved: net/smc: protect clcsock lifetime in smc_getname smc_getname() dereferences smc->clcsock without holding clcsock_release_lock. Link-group termination can release the CLC socket through smc_close_active_abort() while the SMC socket is still open, for example after shutdown(SHUT_WR). A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sock_release() before the caller accesses clcsock->ops or invokes getname(). This causes a use-after-free; if the worker clears the pointer before the load, it causes a NULL dereference. The syscall's file reference keeps the SMC socket alive but does not prevent asynchronous release of its CLC socket. KASAN reported the following with test-only timing instrumentation: BUG: KASAN: slab-use-after-free in smc_getname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smc_getname+0x19e/0x1b0 do_getsockname+0xe5/0x170 __sys_getsockname+0x8c/0x100 Allocated by task 95: sock_alloc_inode+0x1e/0x280 sock_alloc+0x3d/0x240 __sock_create+0x7e/0x430 smc_create+0x121/0x240 Freed by task 0: kmem_cache_free+0xcc/0x340 rcu_core+0x50a/0x1850 Last potentially related work creation: evict+0x446/0x6c0 smc_clcsock_release+0xa8/0xd0 smc_close_active_abort+0x26a/0x3a0 __smc_lgr_terminate.part.0+0x137/0x2e0 Hold clcsock_release_lock across the pointer check and the getname() callback to serialize with smc_clcsock_release().","evidence":"cve:CVE-2026-99032","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99032","aliases":["CVE-2026-99032"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - getsockname(2) on an attacker-owned SMC fd follows __sys_getsockname()->do_getsockname()->smc_getname(), whose unlocked clcsock dereference is the fault; no SMC/TCP message invokes smc_getname(), so a remote peer alone cannot trigger it.\nAC:L - After shutdown(SHUT_WR) moves the socket to SMC_PEERCLOSEWAIT1, the attacker can loop getsockname() while its SMC peer sends LLC DELETE LINK ALL, driving __smc_lgr_terminate()->smc_close_active_abort()->smc_clcsock_release(); both race sides are attacker-controlled.\nPR:L - smc_create() accepts SOCK_STREAM with SMCPROTO_SMC or SMCPROTO_SMC6 without capable() or ns_capable(), while shutdown() and getsockname() require only the socket fd; an ordinary local user can execute the complete path.\nUI:N - The attacker creates and connects the SMC socket, calls shutdown(SHUT_WR), and races getsockname() against termination without requiring another user to mount, open, or approve anything.\nS:U - smc_getname() and the freed CLC socket execute within the same host kernel security authority; this path crosses no guest-host, IOMMU, or other separately governed boundary.\nC:H - The stale struct socket contains both ops and sk; after sock_inode_cache reuse, the indirect getname callback can consume attacker-groomed recycled socket state and return data to userspace, giving the UAF a kernel-memory disclosure primitive.\nI:H - The freed struct socket supplies the indirect ops->getname target and its sk operand; reclaiming it with attacker-created sockets permits callback/operand confusion and mutable kernel-socket access, supporting control-flow or write-oriented exploitation.\nA:H - If smc_clcsock_release() clears the pointer first, smc_getname() dereferences NULL; if freeing follows the caller's load, KASAN confirms a slab use-after-free. Either path can produce a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"e607017a553d2a48e428ec8b8ffb06bf3bb92ce9","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"1512e3714b3946bda75a160a34f22a51710daa43","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"6a1833f0d7dc037c8e876b9178ba69d5d107c086","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"c223da71abfaea2ebb1c7208ae9ebf15038f9388","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"64a6b36b0e1855288080bc5f89769f27d6dc03c8","versionType":"git"},{"status":"affected","version":"0b6153d04c96a1d4b6284692386aa21d04d7956c","versionType":"git"},{"status":"affected","version":"4.19.299","lessThan":"4.20","versionType":"semver"}],"programFiles":["net/smc/af_smc.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.1"},{"status":"unaffected","version":"0","lessThan":"5.1","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/smc/af_smc.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:08.095Z","provider":"cve","references":["https://git.kernel.org/stable/c/e607017a553d2a48e428ec8b8ffb06bf3bb92ce9","https://git.kernel.org/stable/c/1512e3714b3946bda75a160a34f22a51710daa43","https://git.kernel.org/stable/c/6a1833f0d7dc037c8e876b9178ba69d5d107c086","https://git.kernel.org/stable/c/c223da71abfaea2ebb1c7208ae9ebf15038f9388","https://git.kernel.org/stable/c/64a6b36b0e1855288080bc5f89769f27d6dc03c8"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:08.095Z"}}},"related_cves":[{"value":"CVE-2026-99032","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:f7a2d787-76e3-4713-ade4-fa38411da117","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99032","advisory_id":"f7a2d787-76e3-4713-ade4-fa38411da117","event_types":["advisory"],"published_at":"2026-10-25T16:10:43.792016+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:21:36.202+00:00","detail_url":"/advisories/advisory%3Af7a2d787-76e3-4713-ade4-fa38411da117","group":{"id":"advisory:f7a2d787-76e3-4713-ade4-fa38411da117","revision":1,"primary_event_id":55737,"change":"published","superseded_by":[],"changed":{"id":55737,"cve_ids":["CVE-2026-99032"],"payload":{"kind":"advisory","title":"net/smc: protect clcsock lifetime in smc_getname","summary":"In the Linux kernel, the following vulnerability has been resolved: net/smc: protect clcsock lifetime in smc_getname smc_getname() dereferences smc->clcsock without holding clcsock_release_lock. Link-group termination can release the CLC socket through smc_close_active_abort() while the SMC socket is still open, for example after shutdown(SHUT_WR). A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sock_release() before the caller accesses clcsock->ops or invokes getname(). This causes a use-after-free; if the worker clears the pointer before the load, it causes a NULL dereference. The syscall's file reference keeps the SMC socket alive but does not prevent asynchronous release of its CLC socket. KASAN reported the following with test-only timing instrumentation: BUG: KASAN: slab-use-after-free in smc_getname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smc_getname+0x19e/0x1b0 do_getsockname+0xe5/0x170 __sys_getsockname+0x8c/0x100 Allocated by task 95: sock_alloc_inode+0x1e/0x280 sock_alloc+0x3d/0x240 __sock_create+0x7e/0x430 smc_create+0x121/0x240 Freed by task 0: kmem_cache_free+0xcc/0x340 rcu_core+0x50a/0x1850 Last potentially related work creation: evict+0x446/0x6c0 smc_clcsock_release+0xa8/0xd0 smc_close_active_abort+0x26a/0x3a0 __smc_lgr_terminate.part.0+0x137/0x2e0 Hold clcsock_release_lock across the pointer check and the getname() callback to serialize with smc_clcsock_release().","evidence":"cve:CVE-2026-99032","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99032","aliases":["CVE-2026-99032"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - getsockname(2) on an attacker-owned SMC fd follows __sys_getsockname()->do_getsockname()->smc_getname(), whose unlocked clcsock dereference is the fault; no SMC/TCP message invokes smc_getname(), so a remote peer alone cannot trigger it.\nAC:L - After shutdown(SHUT_WR) moves the socket to SMC_PEERCLOSEWAIT1, the attacker can loop getsockname() while its SMC peer sends LLC DELETE LINK ALL, driving __smc_lgr_terminate()->smc_close_active_abort()->smc_clcsock_release(); both race sides are attacker-controlled.\nPR:L - smc_create() accepts SOCK_STREAM with SMCPROTO_SMC or SMCPROTO_SMC6 without capable() or ns_capable(), while shutdown() and getsockname() require only the socket fd; an ordinary local user can execute the complete path.\nUI:N - The attacker creates and connects the SMC socket, calls shutdown(SHUT_WR), and races getsockname() against termination without requiring another user to mount, open, or approve anything.\nS:U - smc_getname() and the freed CLC socket execute within the same host kernel security authority; this path crosses no guest-host, IOMMU, or other separately governed boundary.\nC:H - The stale struct socket contains both ops and sk; after sock_inode_cache reuse, the indirect getname callback can consume attacker-groomed recycled socket state and return data to userspace, giving the UAF a kernel-memory disclosure primitive.\nI:H - The freed struct socket supplies the indirect ops->getname target and its sk operand; reclaiming it with attacker-created sockets permits callback/operand confusion and mutable kernel-socket access, supporting control-flow or write-oriented exploitation.\nA:H - If smc_clcsock_release() clears the pointer first, smc_getname() dereferences NULL; if freeing follows the caller's load, KASAN confirms a slab use-after-free. Either path can produce a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"e607017a553d2a48e428ec8b8ffb06bf3bb92ce9","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"1512e3714b3946bda75a160a34f22a51710daa43","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"6a1833f0d7dc037c8e876b9178ba69d5d107c086","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"c223da71abfaea2ebb1c7208ae9ebf15038f9388","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"64a6b36b0e1855288080bc5f89769f27d6dc03c8","versionType":"git"},{"status":"affected","version":"0b6153d04c96a1d4b6284692386aa21d04d7956c","versionType":"git"},{"status":"affected","version":"4.19.299","lessThan":"4.20","versionType":"semver"}],"programFiles":["net/smc/af_smc.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.1"},{"status":"unaffected","version":"0","lessThan":"5.1","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/smc/af_smc.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:08.095Z","provider":"cve","references":["https://git.kernel.org/stable/c/e607017a553d2a48e428ec8b8ffb06bf3bb92ce9","https://git.kernel.org/stable/c/1512e3714b3946bda75a160a34f22a51710daa43","https://git.kernel.org/stable/c/6a1833f0d7dc037c8e876b9178ba69d5d107c086","https://git.kernel.org/stable/c/c223da71abfaea2ebb1c7208ae9ebf15038f9388","https://git.kernel.org/stable/c/64a6b36b0e1855288080bc5f89769f27d6dc03c8"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:08.095Z"}}},"related_cves":[{"value":"CVE-2026-99032","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:f7a2d787-76e3-4713-ade4-fa38411da117","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99032","advisory_id":"f7a2d787-76e3-4713-ade4-fa38411da117","event_types":["advisory"],"published_at":"2026-10-25T16:10:43.792016+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:21:36.202+00:00","detail_url":"/events/55737"},"members":[{"id":55737,"cve_ids":["CVE-2026-99032"],"payload":{"kind":"advisory","title":"net/smc: protect clcsock lifetime in smc_getname","summary":"In the Linux kernel, the following vulnerability has been resolved: net/smc: protect clcsock lifetime in smc_getname smc_getname() dereferences smc->clcsock without holding clcsock_release_lock. Link-group termination can release the CLC socket through smc_close_active_abort() while the SMC socket is still open, for example after shutdown(SHUT_WR). A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sock_release() before the caller accesses clcsock->ops or invokes getname(). This causes a use-after-free; if the worker clears the pointer before the load, it causes a NULL dereference. The syscall's file reference keeps the SMC socket alive but does not prevent asynchronous release of its CLC socket. KASAN reported the following with test-only timing instrumentation: BUG: KASAN: slab-use-after-free in smc_getname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smc_getname+0x19e/0x1b0 do_getsockname+0xe5/0x170 __sys_getsockname+0x8c/0x100 Allocated by task 95: sock_alloc_inode+0x1e/0x280 sock_alloc+0x3d/0x240 __sock_create+0x7e/0x430 smc_create+0x121/0x240 Freed by task 0: kmem_cache_free+0xcc/0x340 rcu_core+0x50a/0x1850 Last potentially related work creation: evict+0x446/0x6c0 smc_clcsock_release+0xa8/0xd0 smc_close_active_abort+0x26a/0x3a0 __smc_lgr_terminate.part.0+0x137/0x2e0 Hold clcsock_release_lock across the pointer check and the getname() callback to serialize with smc_clcsock_release().","evidence":"cve:CVE-2026-99032","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99032","aliases":["CVE-2026-99032"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - getsockname(2) on an attacker-owned SMC fd follows __sys_getsockname()->do_getsockname()->smc_getname(), whose unlocked clcsock dereference is the fault; no SMC/TCP message invokes smc_getname(), so a remote peer alone cannot trigger it.\nAC:L - After shutdown(SHUT_WR) moves the socket to SMC_PEERCLOSEWAIT1, the attacker can loop getsockname() while its SMC peer sends LLC DELETE LINK ALL, driving __smc_lgr_terminate()->smc_close_active_abort()->smc_clcsock_release(); both race sides are attacker-controlled.\nPR:L - smc_create() accepts SOCK_STREAM with SMCPROTO_SMC or SMCPROTO_SMC6 without capable() or ns_capable(), while shutdown() and getsockname() require only the socket fd; an ordinary local user can execute the complete path.\nUI:N - The attacker creates and connects the SMC socket, calls shutdown(SHUT_WR), and races getsockname() against termination without requiring another user to mount, open, or approve anything.\nS:U - smc_getname() and the freed CLC socket execute within the same host kernel security authority; this path crosses no guest-host, IOMMU, or other separately governed boundary.\nC:H - The stale struct socket contains both ops and sk; after sock_inode_cache reuse, the indirect getname callback can consume attacker-groomed recycled socket state and return data to userspace, giving the UAF a kernel-memory disclosure primitive.\nI:H - The freed struct socket supplies the indirect ops->getname target and its sk operand; reclaiming it with attacker-created sockets permits callback/operand confusion and mutable kernel-socket access, supporting control-flow or write-oriented exploitation.\nA:H - If smc_clcsock_release() clears the pointer first, smc_getname() dereferences NULL; if freeing follows the caller's load, KASAN confirms a slab use-after-free. Either path can produce a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"e607017a553d2a48e428ec8b8ffb06bf3bb92ce9","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"1512e3714b3946bda75a160a34f22a51710daa43","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"6a1833f0d7dc037c8e876b9178ba69d5d107c086","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"c223da71abfaea2ebb1c7208ae9ebf15038f9388","versionType":"git"},{"status":"affected","version":"b03faa1fafc8018295401dc558bdc76362d860a4","lessThan":"64a6b36b0e1855288080bc5f89769f27d6dc03c8","versionType":"git"},{"status":"affected","version":"0b6153d04c96a1d4b6284692386aa21d04d7956c","versionType":"git"},{"status":"affected","version":"4.19.299","lessThan":"4.20","versionType":"semver"}],"programFiles":["net/smc/af_smc.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.1"},{"status":"unaffected","version":"0","lessThan":"5.1","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/smc/af_smc.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:08.095Z","provider":"cve","references":["https://git.kernel.org/stable/c/e607017a553d2a48e428ec8b8ffb06bf3bb92ce9","https://git.kernel.org/stable/c/1512e3714b3946bda75a160a34f22a51710daa43","https://git.kernel.org/stable/c/6a1833f0d7dc037c8e876b9178ba69d5d107c086","https://git.kernel.org/stable/c/c223da71abfaea2ebb1c7208ae9ebf15038f9388","https://git.kernel.org/stable/c/64a6b36b0e1855288080bc5f89769f27d6dc03c8"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:08.095Z"}}},"related_cves":[{"value":"CVE-2026-99032","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:f7a2d787-76e3-4713-ade4-fa38411da117","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99032","advisory_id":"f7a2d787-76e3-4713-ade4-fa38411da117","event_types":["advisory"],"published_at":"2026-10-25T16:10:43.792016+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:21:36.202+00:00","detail_url":"/events/55737"}]}},{"id":56212,"cve_ids":["CVE-2026-99030"],"payload":{"kind":"advisory","title":"net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()","summary":"In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits() When skb_copy_and_csum_bits() reaches unreadable frags it returns 0 after copying only the linear part, and the rest of the caller's buffer is left as it was. The callers copy into a buffer that is about to go out on the wire: an ICMP error quoting the offending packet, or a driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer is zeroed beforehand, so whatever was in memory there gets sent. Zero the part of the buffer we didn't fill. The checksum usually won't match the data any more, so the receiver will usually drop the packet, but either way it no longer carries anything it shouldn't. Only zero for a positive @len, a negative one from a broken caller must not turn into a huge memset().","evidence":"cve:CVE-2026-99030","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99030","aliases":["CVE-2026-99030"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"},"scenarios":[{"lang":"en","value":"AV:N - A remote peer can send an IPv4/TCP segment with an IPOPT_RR length of 2 and payload into a devmem RX flow; ip_rcv() -> ip_rcv_finish_core() -> ip_rcv_options() -> icmp_send() -> icmp_glue_bits() reaches the patched skb_copy_and_csum_bits() while constructing ICMP_PARAMETERPROB.\nAC:L - With documented devmem header splitting and RX-queue binding active, the peer controls the invalid option and payload length, so the unreadable-fragment return and stale transmission occur deterministically; no race or uncontrollable condition is required.\nPR:N - ip_options_compile() emits ICMP_PARAMETERPROB before tcp_v4_rcv() performs TCP-state processing or any application authentication; neither this path nor skb_copy_and_csum_bits() checks a target credential or capability.\nUI:N - The peer's malformed segment alone drives ip_rcv_options() and the ICMP reply; an already-active devmem flow is service configuration, and no victim must respond, open data, or perform another action.\nS:U - The uninitialized ICMP transmit buffer and the prior skb-head contents it exposes are both managed by the same host kernel; the flaw crosses no VM, IOMMU, or sandbox security authority.\nC:H - skb_copy_and_csum_bits() copies only the linear headers and can leave roughly 500 bytes of a 548-byte IPv4 ICMP quote stale in an unzeroed alloc_skb() buffer; repeatable replies transmit prior skb-head contents, supporting substantial remote data harvesting.\nI:N - skb_copy_and_csum_bits() writes the copied header within the allocated destination and merely leaves its tail untouched; there is no out-of-bounds write, attacker-controlled kernel modification, or persistent state corruption.\nA:N - The vulnerable branch returns zero without faulting, looping, or exhausting resources; its incorrect checksum may cause the receiver to drop the ICMP reply, but it does not crash or degrade the target kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"5f19b9cfff79508e8cb09be40d014cb0807f3854","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"5551399751e2c9f31e4f3428040985a07e79d9c2","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"39d1a6b601831237c6038b5e3ac8dbb883c1700a","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"ab9414ed70bd783e902a85c350620dee269bcb2b","versionType":"git"}],"programFiles":["net/core/skbuff.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.12"},{"status":"unaffected","version":"0","lessThan":"6.12","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/core/skbuff.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:06.982Z","provider":"cve","references":["https://git.kernel.org/stable/c/5f19b9cfff79508e8cb09be40d014cb0807f3854","https://git.kernel.org/stable/c/5551399751e2c9f31e4f3428040985a07e79d9c2","https://git.kernel.org/stable/c/39d1a6b601831237c6038b5e3ac8dbb883c1700a","https://git.kernel.org/stable/c/ab9414ed70bd783e902a85c350620dee269bcb2b"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:06.982Z"}}},"related_cves":[{"value":"CVE-2026-99030","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ba3a4360-b952-458a-85e1-5f96fb7e56c3","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99030","advisory_id":"ba3a4360-b952-458a-85e1-5f96fb7e56c3","event_types":["advisory"],"published_at":"2026-10-25T16:10:43.129198+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:21:23.271+00:00","detail_url":"/advisories/advisory%3Aba3a4360-b952-458a-85e1-5f96fb7e56c3","group":{"id":"advisory:ba3a4360-b952-458a-85e1-5f96fb7e56c3","revision":1,"primary_event_id":55736,"change":"published","superseded_by":[],"changed":{"id":55736,"cve_ids":["CVE-2026-99030"],"payload":{"kind":"advisory","title":"net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()","summary":"In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits() When skb_copy_and_csum_bits() reaches unreadable frags it returns 0 after copying only the linear part, and the rest of the caller's buffer is left as it was. The callers copy into a buffer that is about to go out on the wire: an ICMP error quoting the offending packet, or a driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer is zeroed beforehand, so whatever was in memory there gets sent. Zero the part of the buffer we didn't fill. The checksum usually won't match the data any more, so the receiver will usually drop the packet, but either way it no longer carries anything it shouldn't. Only zero for a positive @len, a negative one from a broken caller must not turn into a huge memset().","evidence":"cve:CVE-2026-99030","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99030","aliases":["CVE-2026-99030"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"},"scenarios":[{"lang":"en","value":"AV:N - A remote peer can send an IPv4/TCP segment with an IPOPT_RR length of 2 and payload into a devmem RX flow; ip_rcv() -> ip_rcv_finish_core() -> ip_rcv_options() -> icmp_send() -> icmp_glue_bits() reaches the patched skb_copy_and_csum_bits() while constructing ICMP_PARAMETERPROB.\nAC:L - With documented devmem header splitting and RX-queue binding active, the peer controls the invalid option and payload length, so the unreadable-fragment return and stale transmission occur deterministically; no race or uncontrollable condition is required.\nPR:N - ip_options_compile() emits ICMP_PARAMETERPROB before tcp_v4_rcv() performs TCP-state processing or any application authentication; neither this path nor skb_copy_and_csum_bits() checks a target credential or capability.\nUI:N - The peer's malformed segment alone drives ip_rcv_options() and the ICMP reply; an already-active devmem flow is service configuration, and no victim must respond, open data, or perform another action.\nS:U - The uninitialized ICMP transmit buffer and the prior skb-head contents it exposes are both managed by the same host kernel; the flaw crosses no VM, IOMMU, or sandbox security authority.\nC:H - skb_copy_and_csum_bits() copies only the linear headers and can leave roughly 500 bytes of a 548-byte IPv4 ICMP quote stale in an unzeroed alloc_skb() buffer; repeatable replies transmit prior skb-head contents, supporting substantial remote data harvesting.\nI:N - skb_copy_and_csum_bits() writes the copied header within the allocated destination and merely leaves its tail untouched; there is no out-of-bounds write, attacker-controlled kernel modification, or persistent state corruption.\nA:N - The vulnerable branch returns zero without faulting, looping, or exhausting resources; its incorrect checksum may cause the receiver to drop the ICMP reply, but it does not crash or degrade the target kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"5f19b9cfff79508e8cb09be40d014cb0807f3854","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"5551399751e2c9f31e4f3428040985a07e79d9c2","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"39d1a6b601831237c6038b5e3ac8dbb883c1700a","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"ab9414ed70bd783e902a85c350620dee269bcb2b","versionType":"git"}],"programFiles":["net/core/skbuff.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.12"},{"status":"unaffected","version":"0","lessThan":"6.12","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/core/skbuff.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:06.982Z","provider":"cve","references":["https://git.kernel.org/stable/c/5f19b9cfff79508e8cb09be40d014cb0807f3854","https://git.kernel.org/stable/c/5551399751e2c9f31e4f3428040985a07e79d9c2","https://git.kernel.org/stable/c/39d1a6b601831237c6038b5e3ac8dbb883c1700a","https://git.kernel.org/stable/c/ab9414ed70bd783e902a85c350620dee269bcb2b"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:06.982Z"}}},"related_cves":[{"value":"CVE-2026-99030","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ba3a4360-b952-458a-85e1-5f96fb7e56c3","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99030","advisory_id":"ba3a4360-b952-458a-85e1-5f96fb7e56c3","event_types":["advisory"],"published_at":"2026-10-25T16:10:43.129198+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:21:23.271+00:00","detail_url":"/events/55736"},"members":[{"id":55736,"cve_ids":["CVE-2026-99030"],"payload":{"kind":"advisory","title":"net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()","summary":"In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits() When skb_copy_and_csum_bits() reaches unreadable frags it returns 0 after copying only the linear part, and the rest of the caller's buffer is left as it was. The callers copy into a buffer that is about to go out on the wire: an ICMP error quoting the offending packet, or a driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer is zeroed beforehand, so whatever was in memory there gets sent. Zero the part of the buffer we didn't fill. The checksum usually won't match the data any more, so the receiver will usually drop the packet, but either way it no longer carries anything it shouldn't. Only zero for a positive @len, a negative one from a broken caller must not turn into a huge memset().","evidence":"cve:CVE-2026-99030","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99030","aliases":["CVE-2026-99030"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.5,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"},"scenarios":[{"lang":"en","value":"AV:N - A remote peer can send an IPv4/TCP segment with an IPOPT_RR length of 2 and payload into a devmem RX flow; ip_rcv() -> ip_rcv_finish_core() -> ip_rcv_options() -> icmp_send() -> icmp_glue_bits() reaches the patched skb_copy_and_csum_bits() while constructing ICMP_PARAMETERPROB.\nAC:L - With documented devmem header splitting and RX-queue binding active, the peer controls the invalid option and payload length, so the unreadable-fragment return and stale transmission occur deterministically; no race or uncontrollable condition is required.\nPR:N - ip_options_compile() emits ICMP_PARAMETERPROB before tcp_v4_rcv() performs TCP-state processing or any application authentication; neither this path nor skb_copy_and_csum_bits() checks a target credential or capability.\nUI:N - The peer's malformed segment alone drives ip_rcv_options() and the ICMP reply; an already-active devmem flow is service configuration, and no victim must respond, open data, or perform another action.\nS:U - The uninitialized ICMP transmit buffer and the prior skb-head contents it exposes are both managed by the same host kernel; the flaw crosses no VM, IOMMU, or sandbox security authority.\nC:H - skb_copy_and_csum_bits() copies only the linear headers and can leave roughly 500 bytes of a 548-byte IPv4 ICMP quote stale in an unzeroed alloc_skb() buffer; repeatable replies transmit prior skb-head contents, supporting substantial remote data harvesting.\nI:N - skb_copy_and_csum_bits() writes the copied header within the allocated destination and merely leaves its tail untouched; there is no out-of-bounds write, attacker-controlled kernel modification, or persistent state corruption.\nA:N - The vulnerable branch returns zero without faulting, looping, or exhausting resources; its incorrect checksum may cause the receiver to drop the ICMP reply, but it does not crash or degrade the target kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"5f19b9cfff79508e8cb09be40d014cb0807f3854","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"5551399751e2c9f31e4f3428040985a07e79d9c2","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"39d1a6b601831237c6038b5e3ac8dbb883c1700a","versionType":"git"},{"status":"affected","version":"65249feb6b3df9e17bab5911ee56fa7b0971e231","lessThan":"ab9414ed70bd783e902a85c350620dee269bcb2b","versionType":"git"}],"programFiles":["net/core/skbuff.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.12"},{"status":"unaffected","version":"0","lessThan":"6.12","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/core/skbuff.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:06.982Z","provider":"cve","references":["https://git.kernel.org/stable/c/5f19b9cfff79508e8cb09be40d014cb0807f3854","https://git.kernel.org/stable/c/5551399751e2c9f31e4f3428040985a07e79d9c2","https://git.kernel.org/stable/c/39d1a6b601831237c6038b5e3ac8dbb883c1700a","https://git.kernel.org/stable/c/ab9414ed70bd783e902a85c350620dee269bcb2b"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:06.982Z"}}},"related_cves":[{"value":"CVE-2026-99030","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ba3a4360-b952-458a-85e1-5f96fb7e56c3","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99030","advisory_id":"ba3a4360-b952-458a-85e1-5f96fb7e56c3","event_types":["advisory"],"published_at":"2026-10-25T16:10:43.129198+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:21:23.271+00:00","detail_url":"/events/55736"}]}},{"id":56211,"cve_ids":["CVE-2026-99018"],"payload":{"kind":"advisory","title":"riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel shadow call stack pointer (gp) only when the trap came from userspace. It made that decision with scs_load_current_if_task_changed, which compares the trap-time tp (read back from sscratch into s5) against the current tp: beq \\prev, tp, _skip_scs scs_load_current _skip_scs: tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (¤t) before trapping makes the comparison succeed (can achieve by brute force with KASLR enable under our test), so the kernel skips scs_load_current and keeps running with the gp that userspace left in place. Under CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and load_global_pointer is a no-op, so the compiler-emitted \"sd ra, -8(gp)\" / \"ld ra, -8(gp)\" in every non-leaf function then write to, and return through, an attacker-controlled address -- an unprivileged kernel arbitrary-write and control-flow-hijack primitive. The poisoned gp is saved to task_struct.scs_sp on return, so the reload is skipped on every subsequent entry as well. Decide \"came from userspace\" from the hardware sstatus.SPP bit (already in s1 at this point) instead of from tp, mirroring the check that ret_from_exception already uses a few instructions later. SPP is written by hardware on trap entry and cannot be forg","evidence":"cve:CVE-2026-99018","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99018","aliases":["CVE-2026-99018"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A U-mode RISC-V task controls the ordinary tp/gp registers and executes ecall; stvec enters handle_exception(), whose scs_load_current_if_task_changed macro consumes those values before do_trap_ecall_u. No wire or physical device carries the causal data.\nAC:L - On a CONFIG_SHADOW_CALL_STACK kernel, wrong tp guesses simply invoke scs_load_current, while a match to &current skips it; the fix explicitly reports successfully brute-forcing that match with KASLR enabled. No race or victim-controlled state is required.\nPR:L - The vulnerable comparison occurs in handle_exception() before do_trap_ecall_u reaches syscall_enter_from_user_mode_randomize_stack() or any syscall permission check; U-mode may write tp/gp and execute ecall without capabilities.\nUI:N - After the attacker's own ecall poisons gp, ret_from_exception saves it into task_struct.scs_sp; no victim must open, mount, approve, or race anything.\nS:U - The forged SCS pointer pivots execution inside the same Linux kernel that handles the caller's ecall; the path crosses no KVM guest-host or IOMMU security authority.\nC:H - Because load_global_pointer is a no-op, attacker-selected gp controls compiler SCS loads such as ld ra,-8(gp); the resulting supervisor-mode control-flow hijack permits arbitrary kernel-memory disclosure.\nI:H - Compiler SCS stores such as sd ra,-8(gp) write through the attacker-selected gp to a chosen kernel address, and the corresponding return-address control enables arbitrary kernel code execution.\nA:H - The attacker can direct the SCS store/load at invalid or critical kernel memory from do_trap_ecall_u, causing a supervisor fault, corrupted control flow, and kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"6639735367a7d491977e9e5e7afc50b489d81d83","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"7d1367a53137e379498eb8791295e58854378636","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"37b4401ee6fa06046446d55e97e8d11784080843","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"4d0697f192975dab5985e921989be1d85cf580e9","versionType":"git"}],"programFiles":["arch/riscv/include/asm/scs.h","arch/riscv/kernel/entry.S"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.7"},{"status":"unaffected","version":"0","lessThan":"6.7","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/include/asm/scs.h","arch/riscv/kernel/entry.S"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:05.883Z","provider":"cve","references":["https://git.kernel.org/stable/c/6639735367a7d491977e9e5e7afc50b489d81d83","https://git.kernel.org/stable/c/7d1367a53137e379498eb8791295e58854378636","https://git.kernel.org/stable/c/37b4401ee6fa06046446d55e97e8d11784080843","https://git.kernel.org/stable/c/4d0697f192975dab5985e921989be1d85cf580e9"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:05.883Z"}}},"related_cves":[{"value":"CVE-2026-99018","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6ec11189-50fe-4101-9037-5fb08d89712d","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99018","advisory_id":"6ec11189-50fe-4101-9037-5fb08d89712d","event_types":["advisory"],"published_at":"2026-10-25T16:10:42.457207+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:54.888+00:00","detail_url":"/advisories/advisory%3A6ec11189-50fe-4101-9037-5fb08d89712d","group":{"id":"advisory:6ec11189-50fe-4101-9037-5fb08d89712d","revision":1,"primary_event_id":55735,"change":"published","superseded_by":[],"changed":{"id":55735,"cve_ids":["CVE-2026-99018"],"payload":{"kind":"advisory","title":"riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel shadow call stack pointer (gp) only when the trap came from userspace. It made that decision with scs_load_current_if_task_changed, which compares the trap-time tp (read back from sscratch into s5) against the current tp: beq \\prev, tp, _skip_scs scs_load_current _skip_scs: tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (¤t) before trapping makes the comparison succeed (can achieve by brute force with KASLR enable under our test), so the kernel skips scs_load_current and keeps running with the gp that userspace left in place. Under CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and load_global_pointer is a no-op, so the compiler-emitted \"sd ra, -8(gp)\" / \"ld ra, -8(gp)\" in every non-leaf function then write to, and return through, an attacker-controlled address -- an unprivileged kernel arbitrary-write and control-flow-hijack primitive. The poisoned gp is saved to task_struct.scs_sp on return, so the reload is skipped on every subsequent entry as well. Decide \"came from userspace\" from the hardware sstatus.SPP bit (already in s1 at this point) instead of from tp, mirroring the check that ret_from_exception already uses a few instructions later. SPP is written by hardware on trap entry and cannot be forg","evidence":"cve:CVE-2026-99018","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99018","aliases":["CVE-2026-99018"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A U-mode RISC-V task controls the ordinary tp/gp registers and executes ecall; stvec enters handle_exception(), whose scs_load_current_if_task_changed macro consumes those values before do_trap_ecall_u. No wire or physical device carries the causal data.\nAC:L - On a CONFIG_SHADOW_CALL_STACK kernel, wrong tp guesses simply invoke scs_load_current, while a match to &current skips it; the fix explicitly reports successfully brute-forcing that match with KASLR enabled. No race or victim-controlled state is required.\nPR:L - The vulnerable comparison occurs in handle_exception() before do_trap_ecall_u reaches syscall_enter_from_user_mode_randomize_stack() or any syscall permission check; U-mode may write tp/gp and execute ecall without capabilities.\nUI:N - After the attacker's own ecall poisons gp, ret_from_exception saves it into task_struct.scs_sp; no victim must open, mount, approve, or race anything.\nS:U - The forged SCS pointer pivots execution inside the same Linux kernel that handles the caller's ecall; the path crosses no KVM guest-host or IOMMU security authority.\nC:H - Because load_global_pointer is a no-op, attacker-selected gp controls compiler SCS loads such as ld ra,-8(gp); the resulting supervisor-mode control-flow hijack permits arbitrary kernel-memory disclosure.\nI:H - Compiler SCS stores such as sd ra,-8(gp) write through the attacker-selected gp to a chosen kernel address, and the corresponding return-address control enables arbitrary kernel code execution.\nA:H - The attacker can direct the SCS store/load at invalid or critical kernel memory from do_trap_ecall_u, causing a supervisor fault, corrupted control flow, and kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"6639735367a7d491977e9e5e7afc50b489d81d83","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"7d1367a53137e379498eb8791295e58854378636","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"37b4401ee6fa06046446d55e97e8d11784080843","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"4d0697f192975dab5985e921989be1d85cf580e9","versionType":"git"}],"programFiles":["arch/riscv/include/asm/scs.h","arch/riscv/kernel/entry.S"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.7"},{"status":"unaffected","version":"0","lessThan":"6.7","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/include/asm/scs.h","arch/riscv/kernel/entry.S"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:05.883Z","provider":"cve","references":["https://git.kernel.org/stable/c/6639735367a7d491977e9e5e7afc50b489d81d83","https://git.kernel.org/stable/c/7d1367a53137e379498eb8791295e58854378636","https://git.kernel.org/stable/c/37b4401ee6fa06046446d55e97e8d11784080843","https://git.kernel.org/stable/c/4d0697f192975dab5985e921989be1d85cf580e9"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:05.883Z"}}},"related_cves":[{"value":"CVE-2026-99018","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6ec11189-50fe-4101-9037-5fb08d89712d","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99018","advisory_id":"6ec11189-50fe-4101-9037-5fb08d89712d","event_types":["advisory"],"published_at":"2026-10-25T16:10:42.457207+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:54.888+00:00","detail_url":"/events/55735"},"members":[{"id":55735,"cve_ids":["CVE-2026-99018"],"payload":{"kind":"advisory","title":"riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel shadow call stack pointer (gp) only when the trap came from userspace. It made that decision with scs_load_current_if_task_changed, which compares the trap-time tp (read back from sscratch into s5) against the current tp: beq \\prev, tp, _skip_scs scs_load_current _skip_scs: tp is a user-writable register. A user task that sets tp to the linear-map address of its own task_struct (¤t) before trapping makes the comparison succeed (can achieve by brute force with KASLR enable under our test), so the kernel skips scs_load_current and keeps running with the gp that userspace left in place. Under CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and load_global_pointer is a no-op, so the compiler-emitted \"sd ra, -8(gp)\" / \"ld ra, -8(gp)\" in every non-leaf function then write to, and return through, an attacker-controlled address -- an unprivileged kernel arbitrary-write and control-flow-hijack primitive. The poisoned gp is saved to task_struct.scs_sp on return, so the reload is skipped on every subsequent entry as well. Decide \"came from userspace\" from the hardware sstatus.SPP bit (already in s1 at this point) instead of from tp, mirroring the check that ret_from_exception already uses a few instructions later. SPP is written by hardware on trap entry and cannot be forg","evidence":"cve:CVE-2026-99018","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99018","aliases":["CVE-2026-99018"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A U-mode RISC-V task controls the ordinary tp/gp registers and executes ecall; stvec enters handle_exception(), whose scs_load_current_if_task_changed macro consumes those values before do_trap_ecall_u. No wire or physical device carries the causal data.\nAC:L - On a CONFIG_SHADOW_CALL_STACK kernel, wrong tp guesses simply invoke scs_load_current, while a match to &current skips it; the fix explicitly reports successfully brute-forcing that match with KASLR enabled. No race or victim-controlled state is required.\nPR:L - The vulnerable comparison occurs in handle_exception() before do_trap_ecall_u reaches syscall_enter_from_user_mode_randomize_stack() or any syscall permission check; U-mode may write tp/gp and execute ecall without capabilities.\nUI:N - After the attacker's own ecall poisons gp, ret_from_exception saves it into task_struct.scs_sp; no victim must open, mount, approve, or race anything.\nS:U - The forged SCS pointer pivots execution inside the same Linux kernel that handles the caller's ecall; the path crosses no KVM guest-host or IOMMU security authority.\nC:H - Because load_global_pointer is a no-op, attacker-selected gp controls compiler SCS loads such as ld ra,-8(gp); the resulting supervisor-mode control-flow hijack permits arbitrary kernel-memory disclosure.\nI:H - Compiler SCS stores such as sd ra,-8(gp) write through the attacker-selected gp to a chosen kernel address, and the corresponding return-address control enables arbitrary kernel code execution.\nA:H - The attacker can direct the SCS store/load at invalid or critical kernel memory from do_trap_ecall_u, causing a supervisor fault, corrupted control flow, and kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"6639735367a7d491977e9e5e7afc50b489d81d83","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"7d1367a53137e379498eb8791295e58854378636","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"37b4401ee6fa06046446d55e97e8d11784080843","versionType":"git"},{"status":"affected","version":"d1584d791a297aa8ed93503382a682a6ecfc4218","lessThan":"4d0697f192975dab5985e921989be1d85cf580e9","versionType":"git"}],"programFiles":["arch/riscv/include/asm/scs.h","arch/riscv/kernel/entry.S"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.7"},{"status":"unaffected","version":"0","lessThan":"6.7","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/include/asm/scs.h","arch/riscv/kernel/entry.S"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:05.883Z","provider":"cve","references":["https://git.kernel.org/stable/c/6639735367a7d491977e9e5e7afc50b489d81d83","https://git.kernel.org/stable/c/7d1367a53137e379498eb8791295e58854378636","https://git.kernel.org/stable/c/37b4401ee6fa06046446d55e97e8d11784080843","https://git.kernel.org/stable/c/4d0697f192975dab5985e921989be1d85cf580e9"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:05.883Z"}}},"related_cves":[{"value":"CVE-2026-99018","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:6ec11189-50fe-4101-9037-5fb08d89712d","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99018","advisory_id":"6ec11189-50fe-4101-9037-5fb08d89712d","event_types":["advisory"],"published_at":"2026-10-25T16:10:42.457207+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:54.888+00:00","detail_url":"/events/55735"}]}},{"id":56210,"cve_ids":["CVE-2026-99017"],"payload":{"kind":"advisory","title":"riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE errata_probe_ghostwrite() only marks the CPU as vulnerable when it is called at the RISCV_ALTERNATIVES_EARLY_BOOT stage, and the mitigation in ghostwrite_enable_mitigation() only takes effect if the vulnerable state was recorded before the boot alternatives are patched. The early boot stage is only executed when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled, which currently is only selected by ERRATA_THEAD_MAE. In a kernel built with ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the early alternatives never run, so ghostwrite_state is never set to VULNERABLE: ghostwrite_enable_mitigation() returns false, xtheadvector remains enabled, and sysfs reports \"Not affected\" on a vulnerable T-Head C9xx CPU. Select RISCV_ALTERNATIVE_EARLY from ERRATA_THEAD_GHOSTWRITE so that the vulnerability is detected in the early boot stage and the default mitigation is applied.","evidence":"cve:CVE-2026-99017","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99017","aliases":["CVE-2026-99017"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process executes the GhostWrite vector sequence; its first vector instruction follows handle_exception() through do_trap_insn_illegal() to riscv_v_first_use_handler(), after which the faulty store executes in U-mode. No network protocol carries the causal input.\nAC:H - Exposure requires a vulnerable T-Head C9xx with xtheadvector and the unusual build combination ERRATA_THEAD_GHOSTWRITE=y plus ERRATA_THEAD_MAE=n; both errata options default to y, and an attacker cannot create this kernel configuration.\nPR:L - riscv_v_first_use_handler() and riscv_v_vstate_ctrl_set_current() contain no capability check, so an ordinary local user can enable vector state and execute the sequence; no administrative privilege or user namespace is required.\nUI:N - The attacking process itself enables or first-uses vector state and executes the faulty store; no victim must mount media, open a file, or perform another action.\nS:U - The missed disable_xtheadvector() call lets a user process escalate into the kernel on the same host; this is a local user-to-kernel privilege escalation under the host's existing security authority.\nC:H - Leaving xtheadvector enabled exposes GhostWrite's arbitrary physical-write primitive; overwriting a PTE's page-frame number creates an arbitrary physical-read mapping covering kernel and other-process memory.\nI:H - Because ghostwrite_enable_mitigation() returns false without the early VULNERABLE state, faulty high-order vector stores remain usable for attacker-chosen byte writes to physical memory, including PTEs and kernel or machine-mode code.\nA:H - The same unrestricted physical writes can corrupt kernel text, page tables, or device MMIO, causing an unrecoverable kernel crash or system hang."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"fa465a7819ecbe5801b78c088d3cadaf2664b8ca","versionType":"git"},{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"7fee577a2fa78b9a76da015beec1ccf978746ebb","versionType":"git"},{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"298510bbc7c3017c0faf481c6ea66f1065b657b4","versionType":"git"}],"programFiles":["arch/riscv/Kconfig.errata"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.14"},{"status":"unaffected","version":"0","lessThan":"6.14","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/Kconfig.errata"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:04.808Z","provider":"cve","references":["https://git.kernel.org/stable/c/fa465a7819ecbe5801b78c088d3cadaf2664b8ca","https://git.kernel.org/stable/c/7fee577a2fa78b9a76da015beec1ccf978746ebb","https://git.kernel.org/stable/c/298510bbc7c3017c0faf481c6ea66f1065b657b4"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:04.808Z"}}},"related_cves":[{"value":"CVE-2026-99017","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d253396c-4925-4d8b-9f22-9ddeb7173d90","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99017","advisory_id":"d253396c-4925-4d8b-9f22-9ddeb7173d90","event_types":["advisory"],"published_at":"2026-10-25T16:10:41.608519+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:53.518+00:00","detail_url":"/advisories/advisory%3Ad253396c-4925-4d8b-9f22-9ddeb7173d90","group":{"id":"advisory:d253396c-4925-4d8b-9f22-9ddeb7173d90","revision":1,"primary_event_id":55734,"change":"published","superseded_by":[],"changed":{"id":55734,"cve_ids":["CVE-2026-99017"],"payload":{"kind":"advisory","title":"riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE errata_probe_ghostwrite() only marks the CPU as vulnerable when it is called at the RISCV_ALTERNATIVES_EARLY_BOOT stage, and the mitigation in ghostwrite_enable_mitigation() only takes effect if the vulnerable state was recorded before the boot alternatives are patched. The early boot stage is only executed when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled, which currently is only selected by ERRATA_THEAD_MAE. In a kernel built with ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the early alternatives never run, so ghostwrite_state is never set to VULNERABLE: ghostwrite_enable_mitigation() returns false, xtheadvector remains enabled, and sysfs reports \"Not affected\" on a vulnerable T-Head C9xx CPU. Select RISCV_ALTERNATIVE_EARLY from ERRATA_THEAD_GHOSTWRITE so that the vulnerability is detected in the early boot stage and the default mitigation is applied.","evidence":"cve:CVE-2026-99017","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99017","aliases":["CVE-2026-99017"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process executes the GhostWrite vector sequence; its first vector instruction follows handle_exception() through do_trap_insn_illegal() to riscv_v_first_use_handler(), after which the faulty store executes in U-mode. No network protocol carries the causal input.\nAC:H - Exposure requires a vulnerable T-Head C9xx with xtheadvector and the unusual build combination ERRATA_THEAD_GHOSTWRITE=y plus ERRATA_THEAD_MAE=n; both errata options default to y, and an attacker cannot create this kernel configuration.\nPR:L - riscv_v_first_use_handler() and riscv_v_vstate_ctrl_set_current() contain no capability check, so an ordinary local user can enable vector state and execute the sequence; no administrative privilege or user namespace is required.\nUI:N - The attacking process itself enables or first-uses vector state and executes the faulty store; no victim must mount media, open a file, or perform another action.\nS:U - The missed disable_xtheadvector() call lets a user process escalate into the kernel on the same host; this is a local user-to-kernel privilege escalation under the host's existing security authority.\nC:H - Leaving xtheadvector enabled exposes GhostWrite's arbitrary physical-write primitive; overwriting a PTE's page-frame number creates an arbitrary physical-read mapping covering kernel and other-process memory.\nI:H - Because ghostwrite_enable_mitigation() returns false without the early VULNERABLE state, faulty high-order vector stores remain usable for attacker-chosen byte writes to physical memory, including PTEs and kernel or machine-mode code.\nA:H - The same unrestricted physical writes can corrupt kernel text, page tables, or device MMIO, causing an unrecoverable kernel crash or system hang."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"fa465a7819ecbe5801b78c088d3cadaf2664b8ca","versionType":"git"},{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"7fee577a2fa78b9a76da015beec1ccf978746ebb","versionType":"git"},{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"298510bbc7c3017c0faf481c6ea66f1065b657b4","versionType":"git"}],"programFiles":["arch/riscv/Kconfig.errata"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.14"},{"status":"unaffected","version":"0","lessThan":"6.14","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/Kconfig.errata"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:04.808Z","provider":"cve","references":["https://git.kernel.org/stable/c/fa465a7819ecbe5801b78c088d3cadaf2664b8ca","https://git.kernel.org/stable/c/7fee577a2fa78b9a76da015beec1ccf978746ebb","https://git.kernel.org/stable/c/298510bbc7c3017c0faf481c6ea66f1065b657b4"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:04.808Z"}}},"related_cves":[{"value":"CVE-2026-99017","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d253396c-4925-4d8b-9f22-9ddeb7173d90","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99017","advisory_id":"d253396c-4925-4d8b-9f22-9ddeb7173d90","event_types":["advisory"],"published_at":"2026-10-25T16:10:41.608519+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:53.518+00:00","detail_url":"/events/55734"},"members":[{"id":55734,"cve_ids":["CVE-2026-99017"],"payload":{"kind":"advisory","title":"riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE errata_probe_ghostwrite() only marks the CPU as vulnerable when it is called at the RISCV_ALTERNATIVES_EARLY_BOOT stage, and the mitigation in ghostwrite_enable_mitigation() only takes effect if the vulnerable state was recorded before the boot alternatives are patched. The early boot stage is only executed when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled, which currently is only selected by ERRATA_THEAD_MAE. In a kernel built with ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the early alternatives never run, so ghostwrite_state is never set to VULNERABLE: ghostwrite_enable_mitigation() returns false, xtheadvector remains enabled, and sysfs reports \"Not affected\" on a vulnerable T-Head C9xx CPU. Select RISCV_ALTERNATIVE_EARLY from ERRATA_THEAD_GHOSTWRITE so that the vulnerability is detected in the early boot stage and the default mitigation is applied.","evidence":"cve:CVE-2026-99017","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99017","aliases":["CVE-2026-99017"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process executes the GhostWrite vector sequence; its first vector instruction follows handle_exception() through do_trap_insn_illegal() to riscv_v_first_use_handler(), after which the faulty store executes in U-mode. No network protocol carries the causal input.\nAC:H - Exposure requires a vulnerable T-Head C9xx with xtheadvector and the unusual build combination ERRATA_THEAD_GHOSTWRITE=y plus ERRATA_THEAD_MAE=n; both errata options default to y, and an attacker cannot create this kernel configuration.\nPR:L - riscv_v_first_use_handler() and riscv_v_vstate_ctrl_set_current() contain no capability check, so an ordinary local user can enable vector state and execute the sequence; no administrative privilege or user namespace is required.\nUI:N - The attacking process itself enables or first-uses vector state and executes the faulty store; no victim must mount media, open a file, or perform another action.\nS:U - The missed disable_xtheadvector() call lets a user process escalate into the kernel on the same host; this is a local user-to-kernel privilege escalation under the host's existing security authority.\nC:H - Leaving xtheadvector enabled exposes GhostWrite's arbitrary physical-write primitive; overwriting a PTE's page-frame number creates an arbitrary physical-read mapping covering kernel and other-process memory.\nI:H - Because ghostwrite_enable_mitigation() returns false without the early VULNERABLE state, faulty high-order vector stores remain usable for attacker-chosen byte writes to physical memory, including PTEs and kernel or machine-mode code.\nA:H - The same unrestricted physical writes can corrupt kernel text, page tables, or device MMIO, causing an unrecoverable kernel crash or system hang."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"fa465a7819ecbe5801b78c088d3cadaf2664b8ca","versionType":"git"},{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"7fee577a2fa78b9a76da015beec1ccf978746ebb","versionType":"git"},{"status":"affected","version":"4bf97069239bcfca9840936313c7ac35a6e04488","lessThan":"298510bbc7c3017c0faf481c6ea66f1065b657b4","versionType":"git"}],"programFiles":["arch/riscv/Kconfig.errata"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.14"},{"status":"unaffected","version":"0","lessThan":"6.14","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/Kconfig.errata"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:04.808Z","provider":"cve","references":["https://git.kernel.org/stable/c/fa465a7819ecbe5801b78c088d3cadaf2664b8ca","https://git.kernel.org/stable/c/7fee577a2fa78b9a76da015beec1ccf978746ebb","https://git.kernel.org/stable/c/298510bbc7c3017c0faf481c6ea66f1065b657b4"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:04.808Z"}}},"related_cves":[{"value":"CVE-2026-99017","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d253396c-4925-4d8b-9f22-9ddeb7173d90","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99017","advisory_id":"d253396c-4925-4d8b-9f22-9ddeb7173d90","event_types":["advisory"],"published_at":"2026-10-25T16:10:41.608519+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:53.518+00:00","detail_url":"/events/55734"}]}},{"id":56209,"cve_ids":["CVE-2026-99016"],"payload":{"kind":"advisory","title":"riscv: futex: untag the user pointer before the atomic access","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: futex: untag the user pointer before the atomic access access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm amoswap/amoadd/.../lr.w+sc.w through the \"+m\" (*uaddr) operand. When the tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a user pointer whose top PMLEN bits hold a tag passes access_ok() after untagging, but the atomic is then performed on the still-tagged raw address. Supervisor-mode data accesses are not subject to the U-mode pointer masking (that is governed by menvcfg.PMM, which the kernel does not set), so hardware does not strip the tag for the kernel's own access. With Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a tagged pointer can name a canonical kernel virtual address (e.g. in the linear map) whose untagged form is a valid user address. An unprivileged process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result serving as a read oracle. get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer after the access_ok() check; do the same in the futex helpers so the atomic operates on the address that was actually validated.","evidence":"cve:CVE-2026-99016","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99016","aliases":["CVE-2026-99016"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `sys_futex(FUTEX_WAKE_OP_PRIVATE)` follows `do_futex()` → `futex_wake_op()` → `futex_atomic_op_inuser()` → the patched `arch_futex_atomic_op_inuser()` using attacker-supplied `uaddr2`; no network data reaches this local syscall path.\nAC:L - On an affected Sv57 system supporting PMLEN=16, the attacker deterministically enables tagged addresses with `prctl()` and supplies a canonical linear-map pointer; no race, victim state, or second actor is required.\nPR:L - `sys_prctl(PR_SET_TAGGED_ADDR_CTRL)` and `sys_futex()` contain no capability or credential checks, so an ordinary unprivileged process can enable PMLEN=16 and invoke `FUTEX_WAKE_OP_PRIVATE`.\nUI:N - The attacking process performs both `prctl()` setup and the futex operations itself; no victim must open, mount, approve, or otherwise act.\nS:U - The AMO instructions corrupt the host kernel's own linear-map memory, producing ordinary local kernel privilege escalation without crossing a VM, IOMMU, or separate security authority.\nC:H - The raw-address AMO returns the prior 32-bit kernel value to `futex_atomic_op_inuser()`, whose `FUTEX_OP_CMP_*` result can be observed through controlled waiters, providing a repeatable read oracle over direct-mapped physical memory.\nI:H - `arch_futex_atomic_op_inuser()` executes `amoswap`, `amoadd`, `amoor`, `amoand`, or `amoxor` at the chosen kernel address; SET followed by shifted OR operations permits controlled 32-bit kernel-memory writes and privilege escalation.\nA:H - The same chosen-address AMOs can overwrite direct-mapped kernel objects, credentials, or page-table memory; corrupting such live kernel state can reliably cause an oops, panic, or complete system failure."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"2e5c80bbc062a8dda33e687ebf7be8f074ee4f7d","versionType":"git"},{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"8e48d8d51ab37b7decfbff3e2844e027a52ad6ea","versionType":"git"},{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"405290be962b32eec842776fbe3bdf81f15b1676","versionType":"git"}],"programFiles":["arch/riscv/include/asm/futex.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/include/asm/futex.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:03.722Z","provider":"cve","references":["https://git.kernel.org/stable/c/2e5c80bbc062a8dda33e687ebf7be8f074ee4f7d","https://git.kernel.org/stable/c/8e48d8d51ab37b7decfbff3e2844e027a52ad6ea","https://git.kernel.org/stable/c/405290be962b32eec842776fbe3bdf81f15b1676"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:03.722Z"}}},"related_cves":[{"value":"CVE-2026-99016","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:53274b10-a2d4-4817-ba77-5b68e5b309b3","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99016","advisory_id":"53274b10-a2d4-4817-ba77-5b68e5b309b3","event_types":["advisory"],"published_at":"2026-10-25T16:10:40.935148+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:47.859+00:00","detail_url":"/advisories/advisory%3A53274b10-a2d4-4817-ba77-5b68e5b309b3","group":{"id":"advisory:53274b10-a2d4-4817-ba77-5b68e5b309b3","revision":1,"primary_event_id":55733,"change":"published","superseded_by":[],"changed":{"id":55733,"cve_ids":["CVE-2026-99016"],"payload":{"kind":"advisory","title":"riscv: futex: untag the user pointer before the atomic access","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: futex: untag the user pointer before the atomic access access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm amoswap/amoadd/.../lr.w+sc.w through the \"+m\" (*uaddr) operand. When the tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a user pointer whose top PMLEN bits hold a tag passes access_ok() after untagging, but the atomic is then performed on the still-tagged raw address. Supervisor-mode data accesses are not subject to the U-mode pointer masking (that is governed by menvcfg.PMM, which the kernel does not set), so hardware does not strip the tag for the kernel's own access. With Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a tagged pointer can name a canonical kernel virtual address (e.g. in the linear map) whose untagged form is a valid user address. An unprivileged process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result serving as a read oracle. get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer after the access_ok() check; do the same in the futex helpers so the atomic operates on the address that was actually validated.","evidence":"cve:CVE-2026-99016","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99016","aliases":["CVE-2026-99016"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `sys_futex(FUTEX_WAKE_OP_PRIVATE)` follows `do_futex()` → `futex_wake_op()` → `futex_atomic_op_inuser()` → the patched `arch_futex_atomic_op_inuser()` using attacker-supplied `uaddr2`; no network data reaches this local syscall path.\nAC:L - On an affected Sv57 system supporting PMLEN=16, the attacker deterministically enables tagged addresses with `prctl()` and supplies a canonical linear-map pointer; no race, victim state, or second actor is required.\nPR:L - `sys_prctl(PR_SET_TAGGED_ADDR_CTRL)` and `sys_futex()` contain no capability or credential checks, so an ordinary unprivileged process can enable PMLEN=16 and invoke `FUTEX_WAKE_OP_PRIVATE`.\nUI:N - The attacking process performs both `prctl()` setup and the futex operations itself; no victim must open, mount, approve, or otherwise act.\nS:U - The AMO instructions corrupt the host kernel's own linear-map memory, producing ordinary local kernel privilege escalation without crossing a VM, IOMMU, or separate security authority.\nC:H - The raw-address AMO returns the prior 32-bit kernel value to `futex_atomic_op_inuser()`, whose `FUTEX_OP_CMP_*` result can be observed through controlled waiters, providing a repeatable read oracle over direct-mapped physical memory.\nI:H - `arch_futex_atomic_op_inuser()` executes `amoswap`, `amoadd`, `amoor`, `amoand`, or `amoxor` at the chosen kernel address; SET followed by shifted OR operations permits controlled 32-bit kernel-memory writes and privilege escalation.\nA:H - The same chosen-address AMOs can overwrite direct-mapped kernel objects, credentials, or page-table memory; corrupting such live kernel state can reliably cause an oops, panic, or complete system failure."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"2e5c80bbc062a8dda33e687ebf7be8f074ee4f7d","versionType":"git"},{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"8e48d8d51ab37b7decfbff3e2844e027a52ad6ea","versionType":"git"},{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"405290be962b32eec842776fbe3bdf81f15b1676","versionType":"git"}],"programFiles":["arch/riscv/include/asm/futex.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/include/asm/futex.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:03.722Z","provider":"cve","references":["https://git.kernel.org/stable/c/2e5c80bbc062a8dda33e687ebf7be8f074ee4f7d","https://git.kernel.org/stable/c/8e48d8d51ab37b7decfbff3e2844e027a52ad6ea","https://git.kernel.org/stable/c/405290be962b32eec842776fbe3bdf81f15b1676"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:03.722Z"}}},"related_cves":[{"value":"CVE-2026-99016","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:53274b10-a2d4-4817-ba77-5b68e5b309b3","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99016","advisory_id":"53274b10-a2d4-4817-ba77-5b68e5b309b3","event_types":["advisory"],"published_at":"2026-10-25T16:10:40.935148+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:47.859+00:00","detail_url":"/events/55733"},"members":[{"id":55733,"cve_ids":["CVE-2026-99016"],"payload":{"kind":"advisory","title":"riscv: futex: untag the user pointer before the atomic access","summary":"In the Linux kernel, the following vulnerability has been resolved: riscv: futex: untag the user pointer before the atomic access access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm amoswap/amoadd/.../lr.w+sc.w through the \"+m\" (*uaddr) operand. When the tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a user pointer whose top PMLEN bits hold a tag passes access_ok() after untagging, but the atomic is then performed on the still-tagged raw address. Supervisor-mode data accesses are not subject to the U-mode pointer masking (that is governed by menvcfg.PMM, which the kernel does not set), so hardware does not strip the tag for the kernel's own access. With Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a tagged pointer can name a canonical kernel virtual address (e.g. in the linear map) whose untagged form is a valid user address. An unprivileged process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result serving as a read oracle. get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer after the access_ok() check; do the same in the futex helpers so the atomic operates on the address that was actually validated.","evidence":"cve:CVE-2026-99016","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99016","aliases":["CVE-2026-99016"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - `sys_futex(FUTEX_WAKE_OP_PRIVATE)` follows `do_futex()` → `futex_wake_op()` → `futex_atomic_op_inuser()` → the patched `arch_futex_atomic_op_inuser()` using attacker-supplied `uaddr2`; no network data reaches this local syscall path.\nAC:L - On an affected Sv57 system supporting PMLEN=16, the attacker deterministically enables tagged addresses with `prctl()` and supplies a canonical linear-map pointer; no race, victim state, or second actor is required.\nPR:L - `sys_prctl(PR_SET_TAGGED_ADDR_CTRL)` and `sys_futex()` contain no capability or credential checks, so an ordinary unprivileged process can enable PMLEN=16 and invoke `FUTEX_WAKE_OP_PRIVATE`.\nUI:N - The attacking process performs both `prctl()` setup and the futex operations itself; no victim must open, mount, approve, or otherwise act.\nS:U - The AMO instructions corrupt the host kernel's own linear-map memory, producing ordinary local kernel privilege escalation without crossing a VM, IOMMU, or separate security authority.\nC:H - The raw-address AMO returns the prior 32-bit kernel value to `futex_atomic_op_inuser()`, whose `FUTEX_OP_CMP_*` result can be observed through controlled waiters, providing a repeatable read oracle over direct-mapped physical memory.\nI:H - `arch_futex_atomic_op_inuser()` executes `amoswap`, `amoadd`, `amoor`, `amoand`, or `amoxor` at the chosen kernel address; SET followed by shifted OR operations permits controlled 32-bit kernel-memory writes and privilege escalation.\nA:H - The same chosen-address AMOs can overwrite direct-mapped kernel objects, credentials, or page-table memory; corrupting such live kernel state can reliably cause an oops, panic, or complete system failure."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"2e5c80bbc062a8dda33e687ebf7be8f074ee4f7d","versionType":"git"},{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"8e48d8d51ab37b7decfbff3e2844e027a52ad6ea","versionType":"git"},{"status":"affected","version":"2e1743085887ba3f553c2bb472a75a3ff744b242","lessThan":"405290be962b32eec842776fbe3bdf81f15b1676","versionType":"git"}],"programFiles":["arch/riscv/include/asm/futex.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["arch/riscv/include/asm/futex.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:03.722Z","provider":"cve","references":["https://git.kernel.org/stable/c/2e5c80bbc062a8dda33e687ebf7be8f074ee4f7d","https://git.kernel.org/stable/c/8e48d8d51ab37b7decfbff3e2844e027a52ad6ea","https://git.kernel.org/stable/c/405290be962b32eec842776fbe3bdf81f15b1676"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:03.722Z"}}},"related_cves":[{"value":"CVE-2026-99016","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:53274b10-a2d4-4817-ba77-5b68e5b309b3","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99016","advisory_id":"53274b10-a2d4-4817-ba77-5b68e5b309b3","event_types":["advisory"],"published_at":"2026-10-25T16:10:40.935148+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:47.859+00:00","detail_url":"/events/55733"}]}},{"id":56208,"cve_ids":["CVE-2026-99014"],"payload":{"kind":"advisory","title":"Bluetooth: hci_sync: Fix command skb lifetime during scan setup","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix command skb lifetime during scan setup During PA sync scan setup, hci_le_set_ext_scan_param_sync() gets the address used for the PA_LINK lookup from hci_sent_cmd_data(). The returned pointer borrows storage from sent_cmd or req_skb, without holding a reference to either skb. The scan worker runs on req_workqueue while hci_cmd_work() runs on the separate device workqueue. After the scan worker loads sent_cmd, the command worker can free and replace it before hci_sent_cmd_data() dereferences the skb. The command payload can also be freed between returning from the helper and comparing the address. The connection lookup's RCU critical section does not protect the command skb. KASAN reported: BUG: KASAN: slab-use-after-free in hci_sent_cmd_data+0x27c/0x2f0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_sent_cmd_data+0x27c/0x2f0 hci_le_set_scan_param_sync+0x43a/0x850 hci_passive_scan_sync+0xb09/0x1460 hci_update_passive_scan_sync+0x47c/0x6e0 hci_le_pa_create_sync+0x200/0xa70 hci_cmd_sync_work+0x13c/0x290 Allocated by task 95: skb_clone+0x13f/0x340 hci_cmd_work+0x2a9/0x7e0 Freed by task 95: kmem_cache_free+0xba/0x3a0 hci_cmd_work+0x29c/0x7e0 Use hdev->lock to serialize the address snapshot with sent_cmd replacement. Protect req_skb replacement and completion cleanup with the same lock because the helper falls back to that skb. Copy the address before releasing the lock and use the copy f","evidence":"cve:CVE-2026-99014","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99014","aliases":["CVE-2026-99014"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local listen(2) on a broadcast BTPROTO_ISO socket reaches iso_sock_listen() → iso_listen_bis() → hci_pa_create_sync() → hci_le_pa_create_sync() → hci_le_set_ext_scan_param_sync(). No received Bluetooth PDU initiates this PA-sync setup.\nAC:L - The attacker can run the ISO listen while flooding security-filter-permitted HCI_OP_READ_LOCAL_VERSION commands through a raw HCI socket; hci_sock_sendmsg() queues them on hdev->cmd_q, making hci_cmd_work() race hci_sent_cmd_data() on the separate req_workqueue.\nPR:L - iso_sock_create(), bind(), and listen() have no capability check, while an unprivileged raw HCI socket may submit HCI_OP_READ_LOCAL_VERSION because OGF_INFO_PARAM/OCF 1 is in hci_sec_filter. Bluetooth sockets require init_net, but an ordinary host user satisfies that condition.\nUI:N - The attacking process itself binds and listens on the broadcast ISO socket and submits the racing raw HCI commands; no separate victim action is needed once ISO sockets and the adapter are enabled.\nS:U - The stale sent_cmd or req_skb and resulting memory access remain within the host kernel's Bluetooth authority; hci_le_set_ext_scan_param_sync() crosses no VM, IOMMU, or other security boundary.\nC:H - hci_cmd_data() dereferences len and data from a freed sk_buff, and the returned command-payload pointer can itself be freed before the six-byte bdaddr read. Reclaiming the sprayable skbuff_head_cache object therefore supplies an attacker-directed stale-pointer read primitive.\nI:H - A reclaimed command sk_buff controls the stale len/data fields and the bdaddr used to select a PA_LINK, whose iso_qos then determines the HCI_OP_LE_SET_EXT_SCAN_PARAMS command. This sprayable kernel use-after-free is an integrity-high memory-corruption primitive.\nA:H - KASAN confirmed a slab-use-after-free in hci_sent_cmd_data(); dereferencing the freed sk_buff or its released payload can fault in hci_cmd_sync_work and cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"de3c85d321bfb85b7742a6cfab95d680da3e26b1","lessThan":"f01cbddfb4273fcc9a786d13b0a2525029023605","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"119ba8070b3f112dd36c897f4f70ea5bb7d370b8","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"7db33b36213a3a1a40940c009ddac30670b55922","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"762850c203fab1190ad6a3de41cd51920b22236d","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"9af12272061d206af8bc3e40215cb694421ab73a","versionType":"git"},{"status":"affected","version":"7a54f8314584f78fb0557153b1059924249ef628","versionType":"git"},{"status":"affected","version":"6.6.28","lessThan":"6.6.160","versionType":"semver"},{"status":"affected","version":"6.8.7","lessThan":"6.9","versionType":"semver"}],"programFiles":["net/bluetooth/hci_core.c","net/bluetooth/hci_sync.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.9"},{"status":"unaffected","version":"0","lessThan":"6.9","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/hci_core.c","net/bluetooth/hci_sync.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:02.640Z","provider":"cve","references":["https://git.kernel.org/stable/c/f01cbddfb4273fcc9a786d13b0a2525029023605","https://git.kernel.org/stable/c/119ba8070b3f112dd36c897f4f70ea5bb7d370b8","https://git.kernel.org/stable/c/7db33b36213a3a1a40940c009ddac30670b55922","https://git.kernel.org/stable/c/762850c203fab1190ad6a3de41cd51920b22236d","https://git.kernel.org/stable/c/9af12272061d206af8bc3e40215cb694421ab73a"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:02.640Z"}}},"related_cves":[{"value":"CVE-2026-99014","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ce43ebe2-071e-455f-ada1-d5827fb36d99","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99014","advisory_id":"ce43ebe2-071e-455f-ada1-d5827fb36d99","event_types":["advisory"],"published_at":"2026-10-25T16:10:39.992665+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:39.617+00:00","detail_url":"/advisories/advisory%3Ace43ebe2-071e-455f-ada1-d5827fb36d99","group":{"id":"advisory:ce43ebe2-071e-455f-ada1-d5827fb36d99","revision":1,"primary_event_id":55732,"change":"published","superseded_by":[],"changed":{"id":55732,"cve_ids":["CVE-2026-99014"],"payload":{"kind":"advisory","title":"Bluetooth: hci_sync: Fix command skb lifetime during scan setup","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix command skb lifetime during scan setup During PA sync scan setup, hci_le_set_ext_scan_param_sync() gets the address used for the PA_LINK lookup from hci_sent_cmd_data(). The returned pointer borrows storage from sent_cmd or req_skb, without holding a reference to either skb. The scan worker runs on req_workqueue while hci_cmd_work() runs on the separate device workqueue. After the scan worker loads sent_cmd, the command worker can free and replace it before hci_sent_cmd_data() dereferences the skb. The command payload can also be freed between returning from the helper and comparing the address. The connection lookup's RCU critical section does not protect the command skb. KASAN reported: BUG: KASAN: slab-use-after-free in hci_sent_cmd_data+0x27c/0x2f0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_sent_cmd_data+0x27c/0x2f0 hci_le_set_scan_param_sync+0x43a/0x850 hci_passive_scan_sync+0xb09/0x1460 hci_update_passive_scan_sync+0x47c/0x6e0 hci_le_pa_create_sync+0x200/0xa70 hci_cmd_sync_work+0x13c/0x290 Allocated by task 95: skb_clone+0x13f/0x340 hci_cmd_work+0x2a9/0x7e0 Freed by task 95: kmem_cache_free+0xba/0x3a0 hci_cmd_work+0x29c/0x7e0 Use hdev->lock to serialize the address snapshot with sent_cmd replacement. Protect req_skb replacement and completion cleanup with the same lock because the helper falls back to that skb. Copy the address before releasing the lock and use the copy f","evidence":"cve:CVE-2026-99014","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99014","aliases":["CVE-2026-99014"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local listen(2) on a broadcast BTPROTO_ISO socket reaches iso_sock_listen() → iso_listen_bis() → hci_pa_create_sync() → hci_le_pa_create_sync() → hci_le_set_ext_scan_param_sync(). No received Bluetooth PDU initiates this PA-sync setup.\nAC:L - The attacker can run the ISO listen while flooding security-filter-permitted HCI_OP_READ_LOCAL_VERSION commands through a raw HCI socket; hci_sock_sendmsg() queues them on hdev->cmd_q, making hci_cmd_work() race hci_sent_cmd_data() on the separate req_workqueue.\nPR:L - iso_sock_create(), bind(), and listen() have no capability check, while an unprivileged raw HCI socket may submit HCI_OP_READ_LOCAL_VERSION because OGF_INFO_PARAM/OCF 1 is in hci_sec_filter. Bluetooth sockets require init_net, but an ordinary host user satisfies that condition.\nUI:N - The attacking process itself binds and listens on the broadcast ISO socket and submits the racing raw HCI commands; no separate victim action is needed once ISO sockets and the adapter are enabled.\nS:U - The stale sent_cmd or req_skb and resulting memory access remain within the host kernel's Bluetooth authority; hci_le_set_ext_scan_param_sync() crosses no VM, IOMMU, or other security boundary.\nC:H - hci_cmd_data() dereferences len and data from a freed sk_buff, and the returned command-payload pointer can itself be freed before the six-byte bdaddr read. Reclaiming the sprayable skbuff_head_cache object therefore supplies an attacker-directed stale-pointer read primitive.\nI:H - A reclaimed command sk_buff controls the stale len/data fields and the bdaddr used to select a PA_LINK, whose iso_qos then determines the HCI_OP_LE_SET_EXT_SCAN_PARAMS command. This sprayable kernel use-after-free is an integrity-high memory-corruption primitive.\nA:H - KASAN confirmed a slab-use-after-free in hci_sent_cmd_data(); dereferencing the freed sk_buff or its released payload can fault in hci_cmd_sync_work and cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"de3c85d321bfb85b7742a6cfab95d680da3e26b1","lessThan":"f01cbddfb4273fcc9a786d13b0a2525029023605","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"119ba8070b3f112dd36c897f4f70ea5bb7d370b8","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"7db33b36213a3a1a40940c009ddac30670b55922","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"762850c203fab1190ad6a3de41cd51920b22236d","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"9af12272061d206af8bc3e40215cb694421ab73a","versionType":"git"},{"status":"affected","version":"7a54f8314584f78fb0557153b1059924249ef628","versionType":"git"},{"status":"affected","version":"6.6.28","lessThan":"6.6.160","versionType":"semver"},{"status":"affected","version":"6.8.7","lessThan":"6.9","versionType":"semver"}],"programFiles":["net/bluetooth/hci_core.c","net/bluetooth/hci_sync.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.9"},{"status":"unaffected","version":"0","lessThan":"6.9","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/hci_core.c","net/bluetooth/hci_sync.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:02.640Z","provider":"cve","references":["https://git.kernel.org/stable/c/f01cbddfb4273fcc9a786d13b0a2525029023605","https://git.kernel.org/stable/c/119ba8070b3f112dd36c897f4f70ea5bb7d370b8","https://git.kernel.org/stable/c/7db33b36213a3a1a40940c009ddac30670b55922","https://git.kernel.org/stable/c/762850c203fab1190ad6a3de41cd51920b22236d","https://git.kernel.org/stable/c/9af12272061d206af8bc3e40215cb694421ab73a"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:02.640Z"}}},"related_cves":[{"value":"CVE-2026-99014","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ce43ebe2-071e-455f-ada1-d5827fb36d99","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99014","advisory_id":"ce43ebe2-071e-455f-ada1-d5827fb36d99","event_types":["advisory"],"published_at":"2026-10-25T16:10:39.992665+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:39.617+00:00","detail_url":"/events/55732"},"members":[{"id":55732,"cve_ids":["CVE-2026-99014"],"payload":{"kind":"advisory","title":"Bluetooth: hci_sync: Fix command skb lifetime during scan setup","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix command skb lifetime during scan setup During PA sync scan setup, hci_le_set_ext_scan_param_sync() gets the address used for the PA_LINK lookup from hci_sent_cmd_data(). The returned pointer borrows storage from sent_cmd or req_skb, without holding a reference to either skb. The scan worker runs on req_workqueue while hci_cmd_work() runs on the separate device workqueue. After the scan worker loads sent_cmd, the command worker can free and replace it before hci_sent_cmd_data() dereferences the skb. The command payload can also be freed between returning from the helper and comparing the address. The connection lookup's RCU critical section does not protect the command skb. KASAN reported: BUG: KASAN: slab-use-after-free in hci_sent_cmd_data+0x27c/0x2f0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_sent_cmd_data+0x27c/0x2f0 hci_le_set_scan_param_sync+0x43a/0x850 hci_passive_scan_sync+0xb09/0x1460 hci_update_passive_scan_sync+0x47c/0x6e0 hci_le_pa_create_sync+0x200/0xa70 hci_cmd_sync_work+0x13c/0x290 Allocated by task 95: skb_clone+0x13f/0x340 hci_cmd_work+0x2a9/0x7e0 Freed by task 95: kmem_cache_free+0xba/0x3a0 hci_cmd_work+0x29c/0x7e0 Use hdev->lock to serialize the address snapshot with sent_cmd replacement. Protect req_skb replacement and completion cleanup with the same lock because the helper falls back to that skb. Copy the address before releasing the lock and use the copy f","evidence":"cve:CVE-2026-99014","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99014","aliases":["CVE-2026-99014"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local listen(2) on a broadcast BTPROTO_ISO socket reaches iso_sock_listen() → iso_listen_bis() → hci_pa_create_sync() → hci_le_pa_create_sync() → hci_le_set_ext_scan_param_sync(). No received Bluetooth PDU initiates this PA-sync setup.\nAC:L - The attacker can run the ISO listen while flooding security-filter-permitted HCI_OP_READ_LOCAL_VERSION commands through a raw HCI socket; hci_sock_sendmsg() queues them on hdev->cmd_q, making hci_cmd_work() race hci_sent_cmd_data() on the separate req_workqueue.\nPR:L - iso_sock_create(), bind(), and listen() have no capability check, while an unprivileged raw HCI socket may submit HCI_OP_READ_LOCAL_VERSION because OGF_INFO_PARAM/OCF 1 is in hci_sec_filter. Bluetooth sockets require init_net, but an ordinary host user satisfies that condition.\nUI:N - The attacking process itself binds and listens on the broadcast ISO socket and submits the racing raw HCI commands; no separate victim action is needed once ISO sockets and the adapter are enabled.\nS:U - The stale sent_cmd or req_skb and resulting memory access remain within the host kernel's Bluetooth authority; hci_le_set_ext_scan_param_sync() crosses no VM, IOMMU, or other security boundary.\nC:H - hci_cmd_data() dereferences len and data from a freed sk_buff, and the returned command-payload pointer can itself be freed before the six-byte bdaddr read. Reclaiming the sprayable skbuff_head_cache object therefore supplies an attacker-directed stale-pointer read primitive.\nI:H - A reclaimed command sk_buff controls the stale len/data fields and the bdaddr used to select a PA_LINK, whose iso_qos then determines the HCI_OP_LE_SET_EXT_SCAN_PARAMS command. This sprayable kernel use-after-free is an integrity-high memory-corruption primitive.\nA:H - KASAN confirmed a slab-use-after-free in hci_sent_cmd_data(); dereferencing the freed sk_buff or its released payload can fault in hci_cmd_sync_work and cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"de3c85d321bfb85b7742a6cfab95d680da3e26b1","lessThan":"f01cbddfb4273fcc9a786d13b0a2525029023605","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"119ba8070b3f112dd36c897f4f70ea5bb7d370b8","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"7db33b36213a3a1a40940c009ddac30670b55922","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"762850c203fab1190ad6a3de41cd51920b22236d","versionType":"git"},{"status":"affected","version":"22cbf4f84c00da64196eb15034feee868e63eef0","lessThan":"9af12272061d206af8bc3e40215cb694421ab73a","versionType":"git"},{"status":"affected","version":"7a54f8314584f78fb0557153b1059924249ef628","versionType":"git"},{"status":"affected","version":"6.6.28","lessThan":"6.6.160","versionType":"semver"},{"status":"affected","version":"6.8.7","lessThan":"6.9","versionType":"semver"}],"programFiles":["net/bluetooth/hci_core.c","net/bluetooth/hci_sync.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.9"},{"status":"unaffected","version":"0","lessThan":"6.9","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/hci_core.c","net/bluetooth/hci_sync.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:02.640Z","provider":"cve","references":["https://git.kernel.org/stable/c/f01cbddfb4273fcc9a786d13b0a2525029023605","https://git.kernel.org/stable/c/119ba8070b3f112dd36c897f4f70ea5bb7d370b8","https://git.kernel.org/stable/c/7db33b36213a3a1a40940c009ddac30670b55922","https://git.kernel.org/stable/c/762850c203fab1190ad6a3de41cd51920b22236d","https://git.kernel.org/stable/c/9af12272061d206af8bc3e40215cb694421ab73a"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:02.640Z"}}},"related_cves":[{"value":"CVE-2026-99014","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:ce43ebe2-071e-455f-ada1-d5827fb36d99","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99014","advisory_id":"ce43ebe2-071e-455f-ada1-d5827fb36d99","event_types":["advisory"],"published_at":"2026-10-25T16:10:39.992665+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:39.617+00:00","detail_url":"/events/55732"}]}},{"id":56207,"cve_ids":["CVE-2026-99013"],"payload":{"kind":"advisory","title":"Bluetooth: ISO: Reject concurrent BIS listener setup","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Reject concurrent BIS listener setup iso_sock_listen() drops the socket lock before calling iso_listen_bis() to preserve the hdev->lock ordering. Two concurrent listen() calls on the same broadcast socket can therefore both observe BT_BOUND. Caller A can attach connA and release the locks, then caller B can acquire them and attach connB before A publishes BT_LISTEN. __iso_chan_add() checks whether connB already has a socket, but not whether the socket already has a connection. The second attachment overwrites iso_pi(sk)->conn, leaking the connA reference and leaving connA->sk intact. Socket teardown follows connB, so later events on connA can cause a stale socket access. Recheck BT_BOUND and require iso_pi(sk)->conn to be NULL after taking both the HCI device and socket locks in iso_listen_bis(). The connection check also covers the interval between attachment and publication of BT_LISTEN. Reject a competing setup with -EBADFD through the existing unlock path before allocating another connection. A recorded KASAN report from an instrumented kernel shows: BUG: KASAN: slab-use-after-free in iso_sock_hold+0x119/0x1f0 Call Trace: iso_sock_hold+0x119/0x1f0 iso_conn_del+0xe4/0x270 hci_disconn_complete_evt+0x351/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 93: sk_prot_alloc+0x113/0x220 sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 i","evidence":"cve:CVE-2026-99013","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99013","aliases":["CVE-2026-99013"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The bad state is created by one process issuing two concurrent listen() syscalls on the same bound BTPROTO_ISO socket; __sys_listen_socket() reaches iso_sock_listen() and the patched iso_listen_bis(). An HCI disconnect only consumes the stranded connA->sk, so an adjacent peer cannot create the race alone.\nAC:L - Attacker threads control both listen() calls and can make each observe BT_BOUND before either publishes BT_LISTEN, causing hci_pa_create_sync() to create separate candidates. The attacker can close the socket and end its own broadcast/sync to drive teardown, without victim-controlled timing.\nPR:L - bt_sock_create(), iso_sock_create(), iso_sock_bind(), and iso_sock_listen() contain no capable() or ns_capable() check, so an ordinary process in init_net can create and race the socket. A separate network namespace is rejected, but no user namespace or capability is needed.\nUI:N - The attacker creates and binds the ISO socket, launches both listen() calls, and closes it; the later HCI callback is asynchronous kernel/controller work. No victim action is required.\nS:U - iso_conn_del() corrupts memory within the same host kernel that implements the attacker's ISO socket; the path crosses no VM, IOMMU, or other security authority boundary.\nC:H - After iso_pi(sk)->conn is overwritten, connA retains connA->sk and iso_sock_hold() can refcount a freed or reclaimed kmalloc-2k struct iso_pinfo. Exploiting the ensuing callback-capable socket operations permits control-flow hijack and arbitrary kernel-memory disclosure.\nI:H - iso_conn_del() passes the stale sk to iso_chan_del(), which writes sk_state and sk_err and invokes sk_state_change or parent->sk_data_ready. Reclaiming the freed object can turn these operations into arbitrary writes or control-flow hijacking.\nA:H - KASAN observed the slab use-after-free in iso_sock_hold() from hci_disconn_complete_evt() after iso_sock_release() freed the socket. Invalid refcount, locking, and callback accesses can cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c541d7b5e17987ed330798b07d4ad508859c1c93","lessThan":"559e4d2b6f83aaa96061659cc7104b7a0293f9ef","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"90b744066ca520d1a6a505a11ade9c9a5f48accf","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"79993e9919a87068183ba3622c383f05c049c4bc","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3","versionType":"git"},{"status":"affected","version":"6.12.6","lessThan":"6.12.113","versionType":"semver"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:01.562Z","provider":"cve","references":["https://git.kernel.org/stable/c/559e4d2b6f83aaa96061659cc7104b7a0293f9ef","https://git.kernel.org/stable/c/90b744066ca520d1a6a505a11ade9c9a5f48accf","https://git.kernel.org/stable/c/79993e9919a87068183ba3622c383f05c049c4bc","https://git.kernel.org/stable/c/555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:01.562Z"}}},"related_cves":[{"value":"CVE-2026-99013","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d0e34a96-5c8d-4f18-a4ce-e3492a6ef691","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99013","advisory_id":"d0e34a96-5c8d-4f18-a4ce-e3492a6ef691","event_types":["advisory"],"published_at":"2026-10-25T16:10:39.185023+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:38.612+00:00","detail_url":"/advisories/advisory%3Ad0e34a96-5c8d-4f18-a4ce-e3492a6ef691","group":{"id":"advisory:d0e34a96-5c8d-4f18-a4ce-e3492a6ef691","revision":1,"primary_event_id":55731,"change":"published","superseded_by":[],"changed":{"id":55731,"cve_ids":["CVE-2026-99013"],"payload":{"kind":"advisory","title":"Bluetooth: ISO: Reject concurrent BIS listener setup","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Reject concurrent BIS listener setup iso_sock_listen() drops the socket lock before calling iso_listen_bis() to preserve the hdev->lock ordering. Two concurrent listen() calls on the same broadcast socket can therefore both observe BT_BOUND. Caller A can attach connA and release the locks, then caller B can acquire them and attach connB before A publishes BT_LISTEN. __iso_chan_add() checks whether connB already has a socket, but not whether the socket already has a connection. The second attachment overwrites iso_pi(sk)->conn, leaking the connA reference and leaving connA->sk intact. Socket teardown follows connB, so later events on connA can cause a stale socket access. Recheck BT_BOUND and require iso_pi(sk)->conn to be NULL after taking both the HCI device and socket locks in iso_listen_bis(). The connection check also covers the interval between attachment and publication of BT_LISTEN. Reject a competing setup with -EBADFD through the existing unlock path before allocating another connection. A recorded KASAN report from an instrumented kernel shows: BUG: KASAN: slab-use-after-free in iso_sock_hold+0x119/0x1f0 Call Trace: iso_sock_hold+0x119/0x1f0 iso_conn_del+0xe4/0x270 hci_disconn_complete_evt+0x351/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 93: sk_prot_alloc+0x113/0x220 sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 i","evidence":"cve:CVE-2026-99013","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99013","aliases":["CVE-2026-99013"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The bad state is created by one process issuing two concurrent listen() syscalls on the same bound BTPROTO_ISO socket; __sys_listen_socket() reaches iso_sock_listen() and the patched iso_listen_bis(). An HCI disconnect only consumes the stranded connA->sk, so an adjacent peer cannot create the race alone.\nAC:L - Attacker threads control both listen() calls and can make each observe BT_BOUND before either publishes BT_LISTEN, causing hci_pa_create_sync() to create separate candidates. The attacker can close the socket and end its own broadcast/sync to drive teardown, without victim-controlled timing.\nPR:L - bt_sock_create(), iso_sock_create(), iso_sock_bind(), and iso_sock_listen() contain no capable() or ns_capable() check, so an ordinary process in init_net can create and race the socket. A separate network namespace is rejected, but no user namespace or capability is needed.\nUI:N - The attacker creates and binds the ISO socket, launches both listen() calls, and closes it; the later HCI callback is asynchronous kernel/controller work. No victim action is required.\nS:U - iso_conn_del() corrupts memory within the same host kernel that implements the attacker's ISO socket; the path crosses no VM, IOMMU, or other security authority boundary.\nC:H - After iso_pi(sk)->conn is overwritten, connA retains connA->sk and iso_sock_hold() can refcount a freed or reclaimed kmalloc-2k struct iso_pinfo. Exploiting the ensuing callback-capable socket operations permits control-flow hijack and arbitrary kernel-memory disclosure.\nI:H - iso_conn_del() passes the stale sk to iso_chan_del(), which writes sk_state and sk_err and invokes sk_state_change or parent->sk_data_ready. Reclaiming the freed object can turn these operations into arbitrary writes or control-flow hijacking.\nA:H - KASAN observed the slab use-after-free in iso_sock_hold() from hci_disconn_complete_evt() after iso_sock_release() freed the socket. Invalid refcount, locking, and callback accesses can cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c541d7b5e17987ed330798b07d4ad508859c1c93","lessThan":"559e4d2b6f83aaa96061659cc7104b7a0293f9ef","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"90b744066ca520d1a6a505a11ade9c9a5f48accf","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"79993e9919a87068183ba3622c383f05c049c4bc","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3","versionType":"git"},{"status":"affected","version":"6.12.6","lessThan":"6.12.113","versionType":"semver"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:01.562Z","provider":"cve","references":["https://git.kernel.org/stable/c/559e4d2b6f83aaa96061659cc7104b7a0293f9ef","https://git.kernel.org/stable/c/90b744066ca520d1a6a505a11ade9c9a5f48accf","https://git.kernel.org/stable/c/79993e9919a87068183ba3622c383f05c049c4bc","https://git.kernel.org/stable/c/555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:01.562Z"}}},"related_cves":[{"value":"CVE-2026-99013","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d0e34a96-5c8d-4f18-a4ce-e3492a6ef691","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99013","advisory_id":"d0e34a96-5c8d-4f18-a4ce-e3492a6ef691","event_types":["advisory"],"published_at":"2026-10-25T16:10:39.185023+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:38.612+00:00","detail_url":"/events/55731"},"members":[{"id":55731,"cve_ids":["CVE-2026-99013"],"payload":{"kind":"advisory","title":"Bluetooth: ISO: Reject concurrent BIS listener setup","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Reject concurrent BIS listener setup iso_sock_listen() drops the socket lock before calling iso_listen_bis() to preserve the hdev->lock ordering. Two concurrent listen() calls on the same broadcast socket can therefore both observe BT_BOUND. Caller A can attach connA and release the locks, then caller B can acquire them and attach connB before A publishes BT_LISTEN. __iso_chan_add() checks whether connB already has a socket, but not whether the socket already has a connection. The second attachment overwrites iso_pi(sk)->conn, leaking the connA reference and leaving connA->sk intact. Socket teardown follows connB, so later events on connA can cause a stale socket access. Recheck BT_BOUND and require iso_pi(sk)->conn to be NULL after taking both the HCI device and socket locks in iso_listen_bis(). The connection check also covers the interval between attachment and publication of BT_LISTEN. Reject a competing setup with -EBADFD through the existing unlock path before allocating another connection. A recorded KASAN report from an instrumented kernel shows: BUG: KASAN: slab-use-after-free in iso_sock_hold+0x119/0x1f0 Call Trace: iso_sock_hold+0x119/0x1f0 iso_conn_del+0xe4/0x270 hci_disconn_complete_evt+0x351/0x8c0 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 93: sk_prot_alloc+0x113/0x220 sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 i","evidence":"cve:CVE-2026-99013","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99013","aliases":["CVE-2026-99013"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The bad state is created by one process issuing two concurrent listen() syscalls on the same bound BTPROTO_ISO socket; __sys_listen_socket() reaches iso_sock_listen() and the patched iso_listen_bis(). An HCI disconnect only consumes the stranded connA->sk, so an adjacent peer cannot create the race alone.\nAC:L - Attacker threads control both listen() calls and can make each observe BT_BOUND before either publishes BT_LISTEN, causing hci_pa_create_sync() to create separate candidates. The attacker can close the socket and end its own broadcast/sync to drive teardown, without victim-controlled timing.\nPR:L - bt_sock_create(), iso_sock_create(), iso_sock_bind(), and iso_sock_listen() contain no capable() or ns_capable() check, so an ordinary process in init_net can create and race the socket. A separate network namespace is rejected, but no user namespace or capability is needed.\nUI:N - The attacker creates and binds the ISO socket, launches both listen() calls, and closes it; the later HCI callback is asynchronous kernel/controller work. No victim action is required.\nS:U - iso_conn_del() corrupts memory within the same host kernel that implements the attacker's ISO socket; the path crosses no VM, IOMMU, or other security authority boundary.\nC:H - After iso_pi(sk)->conn is overwritten, connA retains connA->sk and iso_sock_hold() can refcount a freed or reclaimed kmalloc-2k struct iso_pinfo. Exploiting the ensuing callback-capable socket operations permits control-flow hijack and arbitrary kernel-memory disclosure.\nI:H - iso_conn_del() passes the stale sk to iso_chan_del(), which writes sk_state and sk_err and invokes sk_state_change or parent->sk_data_ready. Reclaiming the freed object can turn these operations into arbitrary writes or control-flow hijacking.\nA:H - KASAN observed the slab use-after-free in iso_sock_hold() from hci_disconn_complete_evt() after iso_sock_release() freed the socket. Invalid refcount, locking, and callback accesses can cause a kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"c541d7b5e17987ed330798b07d4ad508859c1c93","lessThan":"559e4d2b6f83aaa96061659cc7104b7a0293f9ef","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"90b744066ca520d1a6a505a11ade9c9a5f48accf","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"79993e9919a87068183ba3622c383f05c049c4bc","versionType":"git"},{"status":"affected","version":"168e28305b871d8ec604a8f51f35467b8d7ba05b","lessThan":"555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3","versionType":"git"},{"status":"affected","version":"6.12.6","lessThan":"6.12.113","versionType":"semver"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:01.562Z","provider":"cve","references":["https://git.kernel.org/stable/c/559e4d2b6f83aaa96061659cc7104b7a0293f9ef","https://git.kernel.org/stable/c/90b744066ca520d1a6a505a11ade9c9a5f48accf","https://git.kernel.org/stable/c/79993e9919a87068183ba3622c383f05c049c4bc","https://git.kernel.org/stable/c/555ff78fa719f50ff4cdbdb40aa1acc6e8e327d3"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:01.562Z"}}},"related_cves":[{"value":"CVE-2026-99013","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:d0e34a96-5c8d-4f18-a4ce-e3492a6ef691","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99013","advisory_id":"d0e34a96-5c8d-4f18-a4ce-e3492a6ef691","event_types":["advisory"],"published_at":"2026-10-25T16:10:39.185023+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:38.612+00:00","detail_url":"/events/55731"}]}},{"id":56206,"cve_ids":["CVE-2026-99011"],"payload":{"kind":"advisory","title":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata() sco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a strong reference under hdev->lock: hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev); but the pointer is cleared from the other side without that lock. When the last sco_conn reference is dropped, sco_conn_free() ran conn->hcon->sco_data = NULL; with no hdev->lock held, so the RX path could read hcon->sco_data and call kref_get_unless_zero() on an sco_conn that was concurrently freed: BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730 kref_get_unless_zero() only guards against a zero refcount, not against the backing memory already being freed. Give hcon->sco_data an actual reference on the sco_conn it points to, so the object cannot be freed while the pointer is still installed, and only clear and drop it from sco_conn_del(), which runs under hdev->lock (its callers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in sco_recv_scodata() also takes hdev->lock, so the store and the read are now serialised: the RX path either observes NULL or a reference that is guaranteed to stay ","evidence":"cve:CVE-2026-99011","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99011","aliases":["CVE-2026-99011"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:A - An in-range peer's Bluetooth SCO/eSCO data enters as HCI_SCODATA_PKT through hci_recv_frame() → hci_rx_work() → hci_scodata_packet() → the patched sco_recv_scodata(). The radio-range transport makes the vector Adjacent.\nAC:H - Peer-induced Disconnection Complete runs on the same ordered HCI workqueue and calls sco_conn_del() under hdev->lock, so it cannot create this race. Exploitation must instead coincide with local close()/shutdown() freeing the sco_conn outside that lock, timing the peer cannot control.\nPR:N - hci_scodata_packet() and sco_recv_scodata() impose no peer credential or capability check once a SCO/eSCO handle exists. For inbound setup, sco_connect_ind() checks only for a listening SCO socket, not authentication.\nUI:R - The last reference must be dropped through victim-side sco_sock_release() or sco_sock_shutdown() while peer data is received. Because peer-driven sco_disconn_cfm() is serialized against receive processing, a separate victim socket teardown is required.\nS:U - The stale hcon->sco_data pointer corrupts a freed sco_conn inside the host Bluetooth kernel stack; it does not cross a VM, IOMMU, or other security-authority boundary.\nC:H - After sco_conn_hold_unless_zero() revives reclaimed storage, sco_recv_frame() reads the reused conn->sk pointer and socket state. Heap grooming can therefore turn the sco_conn UAF into kernel-memory disclosure.\nI:H - kref_get_unless_zero() performs a four-byte atomic increment in the freed sco_conn, followed on success by spinlock and kref operations on reclaimed storage. Reuse can convert these writes into kernel heap corruption and control-flow hijacking.\nA:H - The demonstrated stale reference causes a KASAN slab-use-after-free write in sco_conn_hold_unless_zero() from hci_rx_work; such corruption can produce an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"b108ea7ebba147465f4158d8133f0e8f013762ed","versionType":"git"},{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"8a98d58f6cfe70d51138cd9ce894e72671d95f8a","versionType":"git"},{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"816fb1590a4c8cf8d05cd076057616be02e276f0","versionType":"git"}],"programFiles":["net/bluetooth/sco.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/sco.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:59.382Z","provider":"cve","references":["https://git.kernel.org/stable/c/b108ea7ebba147465f4158d8133f0e8f013762ed","https://git.kernel.org/stable/c/8a98d58f6cfe70d51138cd9ce894e72671d95f8a","https://git.kernel.org/stable/c/816fb1590a4c8cf8d05cd076057616be02e276f0"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:59.382Z"}}},"related_cves":[{"value":"CVE-2026-99011","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2c204410-5463-4ea0-b92a-7bfedd287d9c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99011","advisory_id":"2c204410-5463-4ea0-b92a-7bfedd287d9c","event_types":["advisory"],"published_at":"2026-10-25T16:10:37.979532+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:36.46+00:00","detail_url":"/advisories/advisory%3A2c204410-5463-4ea0-b92a-7bfedd287d9c","group":{"id":"advisory:2c204410-5463-4ea0-b92a-7bfedd287d9c","revision":1,"primary_event_id":55730,"change":"published","superseded_by":[],"changed":{"id":55730,"cve_ids":["CVE-2026-99011"],"payload":{"kind":"advisory","title":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata() sco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a strong reference under hdev->lock: hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev); but the pointer is cleared from the other side without that lock. When the last sco_conn reference is dropped, sco_conn_free() ran conn->hcon->sco_data = NULL; with no hdev->lock held, so the RX path could read hcon->sco_data and call kref_get_unless_zero() on an sco_conn that was concurrently freed: BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730 kref_get_unless_zero() only guards against a zero refcount, not against the backing memory already being freed. Give hcon->sco_data an actual reference on the sco_conn it points to, so the object cannot be freed while the pointer is still installed, and only clear and drop it from sco_conn_del(), which runs under hdev->lock (its callers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in sco_recv_scodata() also takes hdev->lock, so the store and the read are now serialised: the RX path either observes NULL or a reference that is guaranteed to stay ","evidence":"cve:CVE-2026-99011","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99011","aliases":["CVE-2026-99011"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:A - An in-range peer's Bluetooth SCO/eSCO data enters as HCI_SCODATA_PKT through hci_recv_frame() → hci_rx_work() → hci_scodata_packet() → the patched sco_recv_scodata(). The radio-range transport makes the vector Adjacent.\nAC:H - Peer-induced Disconnection Complete runs on the same ordered HCI workqueue and calls sco_conn_del() under hdev->lock, so it cannot create this race. Exploitation must instead coincide with local close()/shutdown() freeing the sco_conn outside that lock, timing the peer cannot control.\nPR:N - hci_scodata_packet() and sco_recv_scodata() impose no peer credential or capability check once a SCO/eSCO handle exists. For inbound setup, sco_connect_ind() checks only for a listening SCO socket, not authentication.\nUI:R - The last reference must be dropped through victim-side sco_sock_release() or sco_sock_shutdown() while peer data is received. Because peer-driven sco_disconn_cfm() is serialized against receive processing, a separate victim socket teardown is required.\nS:U - The stale hcon->sco_data pointer corrupts a freed sco_conn inside the host Bluetooth kernel stack; it does not cross a VM, IOMMU, or other security-authority boundary.\nC:H - After sco_conn_hold_unless_zero() revives reclaimed storage, sco_recv_frame() reads the reused conn->sk pointer and socket state. Heap grooming can therefore turn the sco_conn UAF into kernel-memory disclosure.\nI:H - kref_get_unless_zero() performs a four-byte atomic increment in the freed sco_conn, followed on success by spinlock and kref operations on reclaimed storage. Reuse can convert these writes into kernel heap corruption and control-flow hijacking.\nA:H - The demonstrated stale reference causes a KASAN slab-use-after-free write in sco_conn_hold_unless_zero() from hci_rx_work; such corruption can produce an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"b108ea7ebba147465f4158d8133f0e8f013762ed","versionType":"git"},{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"8a98d58f6cfe70d51138cd9ce894e72671d95f8a","versionType":"git"},{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"816fb1590a4c8cf8d05cd076057616be02e276f0","versionType":"git"}],"programFiles":["net/bluetooth/sco.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/sco.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:59.382Z","provider":"cve","references":["https://git.kernel.org/stable/c/b108ea7ebba147465f4158d8133f0e8f013762ed","https://git.kernel.org/stable/c/8a98d58f6cfe70d51138cd9ce894e72671d95f8a","https://git.kernel.org/stable/c/816fb1590a4c8cf8d05cd076057616be02e276f0"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:59.382Z"}}},"related_cves":[{"value":"CVE-2026-99011","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2c204410-5463-4ea0-b92a-7bfedd287d9c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99011","advisory_id":"2c204410-5463-4ea0-b92a-7bfedd287d9c","event_types":["advisory"],"published_at":"2026-10-25T16:10:37.979532+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:36.46+00:00","detail_url":"/events/55730"},"members":[{"id":55730,"cve_ids":["CVE-2026-99011"],"payload":{"kind":"advisory","title":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata() sco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a strong reference under hdev->lock: hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev); but the pointer is cleared from the other side without that lock. When the last sco_conn reference is dropped, sco_conn_free() ran conn->hcon->sco_data = NULL; with no hdev->lock held, so the RX path could read hcon->sco_data and call kref_get_unless_zero() on an sco_conn that was concurrently freed: BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730 kref_get_unless_zero() only guards against a zero refcount, not against the backing memory already being freed. Give hcon->sco_data an actual reference on the sco_conn it points to, so the object cannot be freed while the pointer is still installed, and only clear and drop it from sco_conn_del(), which runs under hdev->lock (its callers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in sco_recv_scodata() also takes hdev->lock, so the store and the read are now serialised: the RX path either observes NULL or a reference that is guaranteed to stay ","evidence":"cve:CVE-2026-99011","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99011","aliases":["CVE-2026-99011"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:A - An in-range peer's Bluetooth SCO/eSCO data enters as HCI_SCODATA_PKT through hci_recv_frame() → hci_rx_work() → hci_scodata_packet() → the patched sco_recv_scodata(). The radio-range transport makes the vector Adjacent.\nAC:H - Peer-induced Disconnection Complete runs on the same ordered HCI workqueue and calls sco_conn_del() under hdev->lock, so it cannot create this race. Exploitation must instead coincide with local close()/shutdown() freeing the sco_conn outside that lock, timing the peer cannot control.\nPR:N - hci_scodata_packet() and sco_recv_scodata() impose no peer credential or capability check once a SCO/eSCO handle exists. For inbound setup, sco_connect_ind() checks only for a listening SCO socket, not authentication.\nUI:R - The last reference must be dropped through victim-side sco_sock_release() or sco_sock_shutdown() while peer data is received. Because peer-driven sco_disconn_cfm() is serialized against receive processing, a separate victim socket teardown is required.\nS:U - The stale hcon->sco_data pointer corrupts a freed sco_conn inside the host Bluetooth kernel stack; it does not cross a VM, IOMMU, or other security-authority boundary.\nC:H - After sco_conn_hold_unless_zero() revives reclaimed storage, sco_recv_frame() reads the reused conn->sk pointer and socket state. Heap grooming can therefore turn the sco_conn UAF into kernel-memory disclosure.\nI:H - kref_get_unless_zero() performs a four-byte atomic increment in the freed sco_conn, followed on success by spinlock and kref operations on reclaimed storage. Reuse can convert these writes into kernel heap corruption and control-flow hijacking.\nA:H - The demonstrated stale reference causes a KASAN slab-use-after-free write in sco_conn_hold_unless_zero() from hci_rx_work; such corruption can produce an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"b108ea7ebba147465f4158d8133f0e8f013762ed","versionType":"git"},{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"8a98d58f6cfe70d51138cd9ce894e72671d95f8a","versionType":"git"},{"status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","lessThan":"816fb1590a4c8cf8d05cd076057616be02e276f0","versionType":"git"}],"programFiles":["net/bluetooth/sco.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.13"},{"status":"unaffected","version":"0","lessThan":"6.13","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/sco.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:59.382Z","provider":"cve","references":["https://git.kernel.org/stable/c/b108ea7ebba147465f4158d8133f0e8f013762ed","https://git.kernel.org/stable/c/8a98d58f6cfe70d51138cd9ce894e72671d95f8a","https://git.kernel.org/stable/c/816fb1590a4c8cf8d05cd076057616be02e276f0"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:59.382Z"}}},"related_cves":[{"value":"CVE-2026-99011","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2c204410-5463-4ea0-b92a-7bfedd287d9c","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99011","advisory_id":"2c204410-5463-4ea0-b92a-7bfedd287d9c","event_types":["advisory"],"published_at":"2026-10-25T16:10:37.979532+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:36.46+00:00","detail_url":"/events/55730"}]}},{"id":56205,"cve_ids":["CVE-2026-99012"],"payload":{"kind":"advisory","title":"Bluetooth: ISO: Serialize concurrent connect calls","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Serialize concurrent connect calls iso_sock_connect() checks the socket state before taking the socket lock and drops the lock again before setting up a connection. Two callers can both pass the admission check while the socket is open or bound. Caller A can copy its destination for route selection, then caller B can replace the socket destination before A binds or connects the CIS. A then uses B's destination with the route selected for its own request. B can also proceed after A attaches a connection and sets BT_CONNECT. For deferred BIS setup, B can bind a second BIS and overwrite iso_pi(sk)->conn, leaving the first connection's reference and conn->sk back-pointer stranded. Concurrent CIS connects can likewise replace the socket's connection. Later teardown only detaches the current connection, so a callback on the old connection can race with socket release and access a freed socket. KASAN reported: BUG: KASAN: slab-use-after-free in iso_sock_hold+0xf7/0x1b0 Call Trace: iso_sock_hold+0xf7/0x1b0 iso_conn_del+0x7b/0x1d0 iso_connect_cfm+0x186/0x16a0 hci_conn_failed+0x154/0x280 hci_abort_conn_sync+0x3dc/0x7d0 hci_cmd_sync_work+0x173/0x300 Allocated by task 121: sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 iso_sock_create+0x94/0x100 Freed by task 121: kfree+0x121/0x3c0 __sk_destruct+0x42b/0x540 iso_sock_release+0x29d/0x340 __sock_release+0xa1/0x260 Check ad","evidence":"cve:CVE-2026-99012","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99012","aliases":["CVE-2026-99012"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attack begins with two local connect(2) calls on one BTPROTO_ISO socket: __sys_connect() reaches iso_sock_connect(), whose pre-fix unlocked admission check lets both calls overwrite iso_pi(sk)->dst and attach different connections. No received Bluetooth message creates those concurrent calls or supplies the state that causes the overwrite.\nAC:L - A process controls both sides by sharing one socket between threads and issuing concurrent nonblocking connects; the patched BT_SK_CONNECTING flag exists solely to serialize those calls. The stranded conn->sk persists until connection failure or abort, so the attacker can retry and close or spray sockets without depending on victim activity.\nPR:L - bt_sock_create() and iso_sock_create() contain no capable() check, so an ordinary user in init_net can create the required AF_BLUETOOTH/SOCK_SEQPACKET/BTPROTO_ISO socket and call connect(). bt_sock_create() rejects non-initial network namespaces, but no administrative privilege is required in init_net.\nUI:N - The attacker creates, races, and closes their own ISO socket; subsequent hci_conn_failed() -> iso_connect_cfm() -> iso_conn_del() teardown is automatic and needs no victim action.\nS:U - The stale socket pointer is used and corrupted inside the host kernel's Bluetooth/socket memory, yielding an ordinary kernel compromise without crossing a VM, IOMMU, or separate security authority.\nC:H - The overwrite leaves the old iso_conn->sk pointing at a freed, kmalloc-backed struct iso_pinfo; iso_conn_del() passes it through iso_sock_hold() and then reads socket, timer, connection, parent, and callback fields. Controlled heap reclamation makes this kernel UAF usable for high-impact memory disclosure.\nI:H - Through stale conn->sk, iso_sock_hold() increments sk_refcnt and iso_conn_del()/iso_chan_del() manipulate the freed socket's lock, timer work, conn pointer, state, error, and callback. These writes into reclaimed heap memory support pointer/refcount corruption and control-flow hijacking.\nA:H - The commit's KASAN trace demonstrates a slab use-after-free in iso_sock_hold() reached through hci_conn_failed() -> iso_connect_cfm() -> iso_conn_del(); dereferencing or locking the freed struct sock can oops or panic the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"9b6ed57eb8c892ee7566b8c1bd06fdd0053b53de","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"1adcfe232c0f58890c2538211a841100ad0512bd","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"c6489a3a0ac8c07f64cb5b44f005bc518f1048ac","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"3728f6b0d5990c0d500e929ba10baf93bee24f5e","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"e32d80293a0e1a160d5e5101daa8c82148c07510","versionType":"git"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.0"},{"status":"unaffected","version":"0","lessThan":"6.0","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:00.497Z","provider":"cve","references":["https://git.kernel.org/stable/c/9b6ed57eb8c892ee7566b8c1bd06fdd0053b53de","https://git.kernel.org/stable/c/1adcfe232c0f58890c2538211a841100ad0512bd","https://git.kernel.org/stable/c/c6489a3a0ac8c07f64cb5b44f005bc518f1048ac","https://git.kernel.org/stable/c/3728f6b0d5990c0d500e929ba10baf93bee24f5e","https://git.kernel.org/stable/c/e32d80293a0e1a160d5e5101daa8c82148c07510"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:00.497Z"}}},"related_cves":[{"value":"CVE-2026-99012","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:b2cf3908-a64b-49c2-84a6-dd244a310110","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99012","advisory_id":"b2cf3908-a64b-49c2-84a6-dd244a310110","event_types":["advisory"],"published_at":"2026-10-25T16:10:36.780913+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:37.472+00:00","detail_url":"/advisories/advisory%3Ab2cf3908-a64b-49c2-84a6-dd244a310110","group":{"id":"advisory:b2cf3908-a64b-49c2-84a6-dd244a310110","revision":1,"primary_event_id":55729,"change":"published","superseded_by":[],"changed":{"id":55729,"cve_ids":["CVE-2026-99012"],"payload":{"kind":"advisory","title":"Bluetooth: ISO: Serialize concurrent connect calls","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Serialize concurrent connect calls iso_sock_connect() checks the socket state before taking the socket lock and drops the lock again before setting up a connection. Two callers can both pass the admission check while the socket is open or bound. Caller A can copy its destination for route selection, then caller B can replace the socket destination before A binds or connects the CIS. A then uses B's destination with the route selected for its own request. B can also proceed after A attaches a connection and sets BT_CONNECT. For deferred BIS setup, B can bind a second BIS and overwrite iso_pi(sk)->conn, leaving the first connection's reference and conn->sk back-pointer stranded. Concurrent CIS connects can likewise replace the socket's connection. Later teardown only detaches the current connection, so a callback on the old connection can race with socket release and access a freed socket. KASAN reported: BUG: KASAN: slab-use-after-free in iso_sock_hold+0xf7/0x1b0 Call Trace: iso_sock_hold+0xf7/0x1b0 iso_conn_del+0x7b/0x1d0 iso_connect_cfm+0x186/0x16a0 hci_conn_failed+0x154/0x280 hci_abort_conn_sync+0x3dc/0x7d0 hci_cmd_sync_work+0x173/0x300 Allocated by task 121: sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 iso_sock_create+0x94/0x100 Freed by task 121: kfree+0x121/0x3c0 __sk_destruct+0x42b/0x540 iso_sock_release+0x29d/0x340 __sock_release+0xa1/0x260 Check ad","evidence":"cve:CVE-2026-99012","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99012","aliases":["CVE-2026-99012"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attack begins with two local connect(2) calls on one BTPROTO_ISO socket: __sys_connect() reaches iso_sock_connect(), whose pre-fix unlocked admission check lets both calls overwrite iso_pi(sk)->dst and attach different connections. No received Bluetooth message creates those concurrent calls or supplies the state that causes the overwrite.\nAC:L - A process controls both sides by sharing one socket between threads and issuing concurrent nonblocking connects; the patched BT_SK_CONNECTING flag exists solely to serialize those calls. The stranded conn->sk persists until connection failure or abort, so the attacker can retry and close or spray sockets without depending on victim activity.\nPR:L - bt_sock_create() and iso_sock_create() contain no capable() check, so an ordinary user in init_net can create the required AF_BLUETOOTH/SOCK_SEQPACKET/BTPROTO_ISO socket and call connect(). bt_sock_create() rejects non-initial network namespaces, but no administrative privilege is required in init_net.\nUI:N - The attacker creates, races, and closes their own ISO socket; subsequent hci_conn_failed() -> iso_connect_cfm() -> iso_conn_del() teardown is automatic and needs no victim action.\nS:U - The stale socket pointer is used and corrupted inside the host kernel's Bluetooth/socket memory, yielding an ordinary kernel compromise without crossing a VM, IOMMU, or separate security authority.\nC:H - The overwrite leaves the old iso_conn->sk pointing at a freed, kmalloc-backed struct iso_pinfo; iso_conn_del() passes it through iso_sock_hold() and then reads socket, timer, connection, parent, and callback fields. Controlled heap reclamation makes this kernel UAF usable for high-impact memory disclosure.\nI:H - Through stale conn->sk, iso_sock_hold() increments sk_refcnt and iso_conn_del()/iso_chan_del() manipulate the freed socket's lock, timer work, conn pointer, state, error, and callback. These writes into reclaimed heap memory support pointer/refcount corruption and control-flow hijacking.\nA:H - The commit's KASAN trace demonstrates a slab use-after-free in iso_sock_hold() reached through hci_conn_failed() -> iso_connect_cfm() -> iso_conn_del(); dereferencing or locking the freed struct sock can oops or panic the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"9b6ed57eb8c892ee7566b8c1bd06fdd0053b53de","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"1adcfe232c0f58890c2538211a841100ad0512bd","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"c6489a3a0ac8c07f64cb5b44f005bc518f1048ac","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"3728f6b0d5990c0d500e929ba10baf93bee24f5e","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"e32d80293a0e1a160d5e5101daa8c82148c07510","versionType":"git"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.0"},{"status":"unaffected","version":"0","lessThan":"6.0","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:00.497Z","provider":"cve","references":["https://git.kernel.org/stable/c/9b6ed57eb8c892ee7566b8c1bd06fdd0053b53de","https://git.kernel.org/stable/c/1adcfe232c0f58890c2538211a841100ad0512bd","https://git.kernel.org/stable/c/c6489a3a0ac8c07f64cb5b44f005bc518f1048ac","https://git.kernel.org/stable/c/3728f6b0d5990c0d500e929ba10baf93bee24f5e","https://git.kernel.org/stable/c/e32d80293a0e1a160d5e5101daa8c82148c07510"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:00.497Z"}}},"related_cves":[{"value":"CVE-2026-99012","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:b2cf3908-a64b-49c2-84a6-dd244a310110","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99012","advisory_id":"b2cf3908-a64b-49c2-84a6-dd244a310110","event_types":["advisory"],"published_at":"2026-10-25T16:10:36.780913+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:37.472+00:00","detail_url":"/events/55729"},"members":[{"id":55729,"cve_ids":["CVE-2026-99012"],"payload":{"kind":"advisory","title":"Bluetooth: ISO: Serialize concurrent connect calls","summary":"In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Serialize concurrent connect calls iso_sock_connect() checks the socket state before taking the socket lock and drops the lock again before setting up a connection. Two callers can both pass the admission check while the socket is open or bound. Caller A can copy its destination for route selection, then caller B can replace the socket destination before A binds or connects the CIS. A then uses B's destination with the route selected for its own request. B can also proceed after A attaches a connection and sets BT_CONNECT. For deferred BIS setup, B can bind a second BIS and overwrite iso_pi(sk)->conn, leaving the first connection's reference and conn->sk back-pointer stranded. Concurrent CIS connects can likewise replace the socket's connection. Later teardown only detaches the current connection, so a callback on the old connection can race with socket release and access a freed socket. KASAN reported: BUG: KASAN: slab-use-after-free in iso_sock_hold+0xf7/0x1b0 Call Trace: iso_sock_hold+0xf7/0x1b0 iso_conn_del+0x7b/0x1d0 iso_connect_cfm+0x186/0x16a0 hci_conn_failed+0x154/0x280 hci_abort_conn_sync+0x3dc/0x7d0 hci_cmd_sync_work+0x173/0x300 Allocated by task 121: sk_alloc+0x2b/0x6d0 bt_sock_alloc+0x29/0x370 iso_sock_alloc.constprop.0+0x19/0x300 iso_sock_create+0x94/0x100 Freed by task 121: kfree+0x121/0x3c0 __sk_destruct+0x42b/0x540 iso_sock_release+0x29d/0x340 __sock_release+0xa1/0x260 Check ad","evidence":"cve:CVE-2026-99012","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99012","aliases":["CVE-2026-99012"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - The attack begins with two local connect(2) calls on one BTPROTO_ISO socket: __sys_connect() reaches iso_sock_connect(), whose pre-fix unlocked admission check lets both calls overwrite iso_pi(sk)->dst and attach different connections. No received Bluetooth message creates those concurrent calls or supplies the state that causes the overwrite.\nAC:L - A process controls both sides by sharing one socket between threads and issuing concurrent nonblocking connects; the patched BT_SK_CONNECTING flag exists solely to serialize those calls. The stranded conn->sk persists until connection failure or abort, so the attacker can retry and close or spray sockets without depending on victim activity.\nPR:L - bt_sock_create() and iso_sock_create() contain no capable() check, so an ordinary user in init_net can create the required AF_BLUETOOTH/SOCK_SEQPACKET/BTPROTO_ISO socket and call connect(). bt_sock_create() rejects non-initial network namespaces, but no administrative privilege is required in init_net.\nUI:N - The attacker creates, races, and closes their own ISO socket; subsequent hci_conn_failed() -> iso_connect_cfm() -> iso_conn_del() teardown is automatic and needs no victim action.\nS:U - The stale socket pointer is used and corrupted inside the host kernel's Bluetooth/socket memory, yielding an ordinary kernel compromise without crossing a VM, IOMMU, or separate security authority.\nC:H - The overwrite leaves the old iso_conn->sk pointing at a freed, kmalloc-backed struct iso_pinfo; iso_conn_del() passes it through iso_sock_hold() and then reads socket, timer, connection, parent, and callback fields. Controlled heap reclamation makes this kernel UAF usable for high-impact memory disclosure.\nI:H - Through stale conn->sk, iso_sock_hold() increments sk_refcnt and iso_conn_del()/iso_chan_del() manipulate the freed socket's lock, timer work, conn pointer, state, error, and callback. These writes into reclaimed heap memory support pointer/refcount corruption and control-flow hijacking.\nA:H - The commit's KASAN trace demonstrates a slab use-after-free in iso_sock_hold() reached through hci_conn_failed() -> iso_connect_cfm() -> iso_conn_del(); dereferencing or locking the freed struct sock can oops or panic the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"9b6ed57eb8c892ee7566b8c1bd06fdd0053b53de","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"1adcfe232c0f58890c2538211a841100ad0512bd","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"c6489a3a0ac8c07f64cb5b44f005bc518f1048ac","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"3728f6b0d5990c0d500e929ba10baf93bee24f5e","versionType":"git"},{"status":"affected","version":"ccf74f2390d60a2f9a75ef496d2564abb478f46a","lessThan":"e32d80293a0e1a160d5e5101daa8c82148c07510","versionType":"git"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.0"},{"status":"unaffected","version":"0","lessThan":"6.0","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["net/bluetooth/iso.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:10:00.497Z","provider":"cve","references":["https://git.kernel.org/stable/c/9b6ed57eb8c892ee7566b8c1bd06fdd0053b53de","https://git.kernel.org/stable/c/1adcfe232c0f58890c2538211a841100ad0512bd","https://git.kernel.org/stable/c/c6489a3a0ac8c07f64cb5b44f005bc518f1048ac","https://git.kernel.org/stable/c/3728f6b0d5990c0d500e929ba10baf93bee24f5e","https://git.kernel.org/stable/c/e32d80293a0e1a160d5e5101daa8c82148c07510"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:10:00.497Z"}}},"related_cves":[{"value":"CVE-2026-99012","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:b2cf3908-a64b-49c2-84a6-dd244a310110","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99012","advisory_id":"b2cf3908-a64b-49c2-84a6-dd244a310110","event_types":["advisory"],"published_at":"2026-10-25T16:10:36.780913+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:37.472+00:00","detail_url":"/events/55729"}]}},{"id":56204,"cve_ids":["CVE-2026-99006"],"payload":{"kind":"advisory","title":"drm/i915/gem: Prevent overstepping exec array boundary","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Prevent overstepping exec array boundary It is possible for eb_relocate_parse_slow() to call kvfree() on entries outside the original exec array during following scenario inside eb_relocate_parse_slow(): 1) eb_copy_relocations() allocates as many as eb->buffer_count copies for exec entries; 2) eb_parse() appends up to two VMAs, right after incrementing eb->buffer_count; 3) cleanup under \"out\" label uses this incremented buffer_count to release relocation pointers from exec array via kvfree(), not from VMA array. To amend this problem, ensure that relocation cleanup uses the original exec object count, excluding the VMAs appended by the command parser. (cherry picked from commit 2a0158925fb943c7ba8f3216e2734952128defc9)","evidence":"cve:CVE-2026-99006","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99006","aliases":["CVE-2026-99006"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process reaches the patched cleanup through ioctl(2) → drm_ioctl() → i915_gem_execbuffer2_ioctl() → i915_gem_do_execbuffer() → eb_relocate_parse_slow(); the exec and relocation arrays originate in local userspace, not a wire protocol.\nAC:L - On affected parser-enabled i915 hardware, the caller controls its relocs_ptr mapping to force eb_copy_relocations(), then submits a parser-using batch so eb_parse() appends VMAs. Any mapping race and heap grooming are controlled by the same caller and can be retried.\nPR:L - I915_GEM_EXECBUFFER2_WR is registered with DRM_RENDER_ALLOW, and drm_ioctl_permit() imposes no DRM_AUTH, DRM_MASTER, DRM_ROOT_ONLY, or CAP_SYS_ADMIN check; an ordinary user with render-node access can invoke it.\nUI:N - The attacker opens the i915 render node, prepares GEM objects and relocation arrays, and issues the execbuffer ioctl directly; no action by another user is required.\nS:U - The erroneous kvfree() corrupts the host kernel heap from a host userspace client, constituting ordinary local-to-kernel escalation without crossing a VM, IOMMU, or other distinct security authority.\nC:H - After eb_parse() increments buffer_count, eb_relocate_parse_slow() reads an untouched post-array slot as an exec object and passes its stale relocs_ptr to kvfree(); reusing a previously freed relocation-copy pointer produces a heap UAF capable of exposing kernel memory.\nI:H - The attacker-groomable kvfree() can double-free or prematurely free a live allocation referenced through the stale relocs_ptr; reclaiming that object while stale users remain provides heap-corruption and control-flow-hijacking primitives.\nA:H - kvfree() of the out-of-array relocs_ptr can immediately oops in kfree() for an invalid address or corrupt the allocator through a double-free; repeated execbuffer submissions can therefore crash or panic the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"24c04e80c35ff36947366f6deafddb522eea080c","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"b1c357131fc467c579f65e9a9d1fdc1a6273ae1d","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"152fb5083b9333a1cb8629572f9e0f276a404ba6","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"72d5cbb10d4916a3f8ef9da516c5c0634aca8439","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"ebe162db655881a38de43301151ff7ac940602b5","versionType":"git"}],"programFiles":["drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.10"},{"status":"unaffected","version":"0","lessThan":"5.10","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:58.315Z","provider":"cve","references":["https://git.kernel.org/stable/c/24c04e80c35ff36947366f6deafddb522eea080c","https://git.kernel.org/stable/c/b1c357131fc467c579f65e9a9d1fdc1a6273ae1d","https://git.kernel.org/stable/c/152fb5083b9333a1cb8629572f9e0f276a404ba6","https://git.kernel.org/stable/c/72d5cbb10d4916a3f8ef9da516c5c0634aca8439","https://git.kernel.org/stable/c/ebe162db655881a38de43301151ff7ac940602b5"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:58.315Z"}}},"related_cves":[{"value":"CVE-2026-99006","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:a3724deb-abb6-4c1b-9532-016141c0d6a5","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99006","advisory_id":"a3724deb-abb6-4c1b-9532-016141c0d6a5","event_types":["advisory"],"published_at":"2026-10-25T16:10:35.551231+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:31.415+00:00","detail_url":"/advisories/advisory%3Aa3724deb-abb6-4c1b-9532-016141c0d6a5","group":{"id":"advisory:a3724deb-abb6-4c1b-9532-016141c0d6a5","revision":1,"primary_event_id":55728,"change":"published","superseded_by":[],"changed":{"id":55728,"cve_ids":["CVE-2026-99006"],"payload":{"kind":"advisory","title":"drm/i915/gem: Prevent overstepping exec array boundary","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Prevent overstepping exec array boundary It is possible for eb_relocate_parse_slow() to call kvfree() on entries outside the original exec array during following scenario inside eb_relocate_parse_slow(): 1) eb_copy_relocations() allocates as many as eb->buffer_count copies for exec entries; 2) eb_parse() appends up to two VMAs, right after incrementing eb->buffer_count; 3) cleanup under \"out\" label uses this incremented buffer_count to release relocation pointers from exec array via kvfree(), not from VMA array. To amend this problem, ensure that relocation cleanup uses the original exec object count, excluding the VMAs appended by the command parser. (cherry picked from commit 2a0158925fb943c7ba8f3216e2734952128defc9)","evidence":"cve:CVE-2026-99006","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99006","aliases":["CVE-2026-99006"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process reaches the patched cleanup through ioctl(2) → drm_ioctl() → i915_gem_execbuffer2_ioctl() → i915_gem_do_execbuffer() → eb_relocate_parse_slow(); the exec and relocation arrays originate in local userspace, not a wire protocol.\nAC:L - On affected parser-enabled i915 hardware, the caller controls its relocs_ptr mapping to force eb_copy_relocations(), then submits a parser-using batch so eb_parse() appends VMAs. Any mapping race and heap grooming are controlled by the same caller and can be retried.\nPR:L - I915_GEM_EXECBUFFER2_WR is registered with DRM_RENDER_ALLOW, and drm_ioctl_permit() imposes no DRM_AUTH, DRM_MASTER, DRM_ROOT_ONLY, or CAP_SYS_ADMIN check; an ordinary user with render-node access can invoke it.\nUI:N - The attacker opens the i915 render node, prepares GEM objects and relocation arrays, and issues the execbuffer ioctl directly; no action by another user is required.\nS:U - The erroneous kvfree() corrupts the host kernel heap from a host userspace client, constituting ordinary local-to-kernel escalation without crossing a VM, IOMMU, or other distinct security authority.\nC:H - After eb_parse() increments buffer_count, eb_relocate_parse_slow() reads an untouched post-array slot as an exec object and passes its stale relocs_ptr to kvfree(); reusing a previously freed relocation-copy pointer produces a heap UAF capable of exposing kernel memory.\nI:H - The attacker-groomable kvfree() can double-free or prematurely free a live allocation referenced through the stale relocs_ptr; reclaiming that object while stale users remain provides heap-corruption and control-flow-hijacking primitives.\nA:H - kvfree() of the out-of-array relocs_ptr can immediately oops in kfree() for an invalid address or corrupt the allocator through a double-free; repeated execbuffer submissions can therefore crash or panic the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"24c04e80c35ff36947366f6deafddb522eea080c","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"b1c357131fc467c579f65e9a9d1fdc1a6273ae1d","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"152fb5083b9333a1cb8629572f9e0f276a404ba6","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"72d5cbb10d4916a3f8ef9da516c5c0634aca8439","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"ebe162db655881a38de43301151ff7ac940602b5","versionType":"git"}],"programFiles":["drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.10"},{"status":"unaffected","version":"0","lessThan":"5.10","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:58.315Z","provider":"cve","references":["https://git.kernel.org/stable/c/24c04e80c35ff36947366f6deafddb522eea080c","https://git.kernel.org/stable/c/b1c357131fc467c579f65e9a9d1fdc1a6273ae1d","https://git.kernel.org/stable/c/152fb5083b9333a1cb8629572f9e0f276a404ba6","https://git.kernel.org/stable/c/72d5cbb10d4916a3f8ef9da516c5c0634aca8439","https://git.kernel.org/stable/c/ebe162db655881a38de43301151ff7ac940602b5"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:58.315Z"}}},"related_cves":[{"value":"CVE-2026-99006","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:a3724deb-abb6-4c1b-9532-016141c0d6a5","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99006","advisory_id":"a3724deb-abb6-4c1b-9532-016141c0d6a5","event_types":["advisory"],"published_at":"2026-10-25T16:10:35.551231+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:31.415+00:00","detail_url":"/events/55728"},"members":[{"id":55728,"cve_ids":["CVE-2026-99006"],"payload":{"kind":"advisory","title":"drm/i915/gem: Prevent overstepping exec array boundary","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Prevent overstepping exec array boundary It is possible for eb_relocate_parse_slow() to call kvfree() on entries outside the original exec array during following scenario inside eb_relocate_parse_slow(): 1) eb_copy_relocations() allocates as many as eb->buffer_count copies for exec entries; 2) eb_parse() appends up to two VMAs, right after incrementing eb->buffer_count; 3) cleanup under \"out\" label uses this incremented buffer_count to release relocation pointers from exec array via kvfree(), not from VMA array. To amend this problem, ensure that relocation cleanup uses the original exec object count, excluding the VMAs appended by the command parser. (cherry picked from commit 2a0158925fb943c7ba8f3216e2734952128defc9)","evidence":"cve:CVE-2026-99006","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99006","aliases":["CVE-2026-99006"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - A local process reaches the patched cleanup through ioctl(2) → drm_ioctl() → i915_gem_execbuffer2_ioctl() → i915_gem_do_execbuffer() → eb_relocate_parse_slow(); the exec and relocation arrays originate in local userspace, not a wire protocol.\nAC:L - On affected parser-enabled i915 hardware, the caller controls its relocs_ptr mapping to force eb_copy_relocations(), then submits a parser-using batch so eb_parse() appends VMAs. Any mapping race and heap grooming are controlled by the same caller and can be retried.\nPR:L - I915_GEM_EXECBUFFER2_WR is registered with DRM_RENDER_ALLOW, and drm_ioctl_permit() imposes no DRM_AUTH, DRM_MASTER, DRM_ROOT_ONLY, or CAP_SYS_ADMIN check; an ordinary user with render-node access can invoke it.\nUI:N - The attacker opens the i915 render node, prepares GEM objects and relocation arrays, and issues the execbuffer ioctl directly; no action by another user is required.\nS:U - The erroneous kvfree() corrupts the host kernel heap from a host userspace client, constituting ordinary local-to-kernel escalation without crossing a VM, IOMMU, or other distinct security authority.\nC:H - After eb_parse() increments buffer_count, eb_relocate_parse_slow() reads an untouched post-array slot as an exec object and passes its stale relocs_ptr to kvfree(); reusing a previously freed relocation-copy pointer produces a heap UAF capable of exposing kernel memory.\nI:H - The attacker-groomable kvfree() can double-free or prematurely free a live allocation referenced through the stale relocs_ptr; reclaiming that object while stale users remain provides heap-corruption and control-flow-hijacking primitives.\nA:H - kvfree() of the out-of-array relocs_ptr can immediately oops in kfree() for an invalid address or corrupt the allocator through a double-free; repeated execbuffer submissions can therefore crash or panic the kernel."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"24c04e80c35ff36947366f6deafddb522eea080c","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"b1c357131fc467c579f65e9a9d1fdc1a6273ae1d","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"152fb5083b9333a1cb8629572f9e0f276a404ba6","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"72d5cbb10d4916a3f8ef9da516c5c0634aca8439","versionType":"git"},{"status":"affected","version":"8e4ba491b0ba6fef69270d3c4e48fc517096ef41","lessThan":"ebe162db655881a38de43301151ff7ac940602b5","versionType":"git"}],"programFiles":["drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"5.10"},{"status":"unaffected","version":"0","lessThan":"5.10","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.113","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:58.315Z","provider":"cve","references":["https://git.kernel.org/stable/c/24c04e80c35ff36947366f6deafddb522eea080c","https://git.kernel.org/stable/c/b1c357131fc467c579f65e9a9d1fdc1a6273ae1d","https://git.kernel.org/stable/c/152fb5083b9333a1cb8629572f9e0f276a404ba6","https://git.kernel.org/stable/c/72d5cbb10d4916a3f8ef9da516c5c0634aca8439","https://git.kernel.org/stable/c/ebe162db655881a38de43301151ff7ac940602b5"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:58.315Z"}}},"related_cves":[{"value":"CVE-2026-99006","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:a3724deb-abb6-4c1b-9532-016141c0d6a5","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99006","advisory_id":"a3724deb-abb6-4c1b-9532-016141c0d6a5","event_types":["advisory"],"published_at":"2026-10-25T16:10:35.551231+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:31.415+00:00","detail_url":"/events/55728"}]}},{"id":56203,"cve_ids":["CVE-2026-99002"],"payload":{"kind":"advisory","title":"drm/vmwgfx: validate pitch coming from userspace","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate pitch coming from userspace Validate the pitch, alongside the box dimensions before trying to copy data from the underlying surface. Fixes possible out of bounds reads with cursor snooping.","evidence":"cve:CVE-2026-99002","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99002","aliases":["CVE-2026-99002"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - DRM_IOCTL_VMW_EXECBUF passes a locally supplied SVGA_3D_CMD_SURFACE_DMA through vmw_execbuf_process(), vmw_cmd_dma(), and vmw_kms_cursor_snoop(); the malformed guest.pitch and copy box originate in this ioctl, not a network protocol.\nAC:L - The attacker can create the required 64x64 A8R8G8B8 scanout surface and choose the box, pitch, and source BO. A 63x64 box with pitch 256 deterministically reaches the corrupting partial-copy loop without a race or attacker-uncontrolled condition.\nPR:L - VMW_CREATE_SURFACE, VMW_ALLOC_DMABUF, and VMW_EXECBUF are DRM_RENDER_ALLOW on a DRIVER_RENDER device; drm_ioctl_permit() therefore requires no DRM master, authentication, or capability from an unprivileged render-node client.\nUI:N - The attacker creates the surface and BO and submits the malformed DMA command through their own file descriptor; no victim must mount, open, or display anything.\nS:U - vmw_kms_cursor_snoop() corrupts the guest kernel's own cursor-snooper allocation from guest userspace. The code demonstrates neither host-memory corruption nor a guest-to-host or IOMMU-boundary escape.\nC:H - The unchecked pitch causes out-of-bounds source reads, while the attacker-controlled heap overwrite can corrupt neighboring pointer-bearing objects and be developed into arbitrary guest-kernel read primitives.\nI:H - snooper.image is a u32 pointer, but the vulnerable loop uses the 256-byte image_pitch as an element stride; a 63x64 copy writes controlled 252-byte rows at 1024-byte intervals far beyond the 16-KiB allocation, enabling control-flow hijacking.\nA:H - An excessive pitch can fault while reading beyond the TTM mapping, and the partial-copy destination bug can overwrite roughly 48 KiB beyond the snooper image, causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"db6fbc2b77849e3c3c2bc115ea9ac925c4625a0d","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"f6d9c8abdf06a9c7efa799532d66ed8d5a50734c","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"76e5ddd7d9822c8c3492e0f50ba8978e093069ad","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"fcb137f6e7ed769f7ecad84364a33c451371b602","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"21bc51cb89ced74d6645a138cc2f21184bc75094","versionType":"git"}],"programFiles":["drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.2"},{"status":"unaffected","version":"0","lessThan":"3.2","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:57.241Z","provider":"cve","references":["https://git.kernel.org/stable/c/db6fbc2b77849e3c3c2bc115ea9ac925c4625a0d","https://git.kernel.org/stable/c/f6d9c8abdf06a9c7efa799532d66ed8d5a50734c","https://git.kernel.org/stable/c/76e5ddd7d9822c8c3492e0f50ba8978e093069ad","https://git.kernel.org/stable/c/fcb137f6e7ed769f7ecad84364a33c451371b602","https://git.kernel.org/stable/c/21bc51cb89ced74d6645a138cc2f21184bc75094"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:57.241Z"}}},"related_cves":[{"value":"CVE-2026-99002","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:4554c98e-1467-4505-8a51-1e97fbf49bac","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99002","advisory_id":"4554c98e-1467-4505-8a51-1e97fbf49bac","event_types":["advisory"],"published_at":"2026-10-25T16:10:34.475267+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:22.763+00:00","detail_url":"/advisories/advisory%3A4554c98e-1467-4505-8a51-1e97fbf49bac","group":{"id":"advisory:4554c98e-1467-4505-8a51-1e97fbf49bac","revision":1,"primary_event_id":55727,"change":"published","superseded_by":[],"changed":{"id":55727,"cve_ids":["CVE-2026-99002"],"payload":{"kind":"advisory","title":"drm/vmwgfx: validate pitch coming from userspace","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate pitch coming from userspace Validate the pitch, alongside the box dimensions before trying to copy data from the underlying surface. Fixes possible out of bounds reads with cursor snooping.","evidence":"cve:CVE-2026-99002","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99002","aliases":["CVE-2026-99002"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - DRM_IOCTL_VMW_EXECBUF passes a locally supplied SVGA_3D_CMD_SURFACE_DMA through vmw_execbuf_process(), vmw_cmd_dma(), and vmw_kms_cursor_snoop(); the malformed guest.pitch and copy box originate in this ioctl, not a network protocol.\nAC:L - The attacker can create the required 64x64 A8R8G8B8 scanout surface and choose the box, pitch, and source BO. A 63x64 box with pitch 256 deterministically reaches the corrupting partial-copy loop without a race or attacker-uncontrolled condition.\nPR:L - VMW_CREATE_SURFACE, VMW_ALLOC_DMABUF, and VMW_EXECBUF are DRM_RENDER_ALLOW on a DRIVER_RENDER device; drm_ioctl_permit() therefore requires no DRM master, authentication, or capability from an unprivileged render-node client.\nUI:N - The attacker creates the surface and BO and submits the malformed DMA command through their own file descriptor; no victim must mount, open, or display anything.\nS:U - vmw_kms_cursor_snoop() corrupts the guest kernel's own cursor-snooper allocation from guest userspace. The code demonstrates neither host-memory corruption nor a guest-to-host or IOMMU-boundary escape.\nC:H - The unchecked pitch causes out-of-bounds source reads, while the attacker-controlled heap overwrite can corrupt neighboring pointer-bearing objects and be developed into arbitrary guest-kernel read primitives.\nI:H - snooper.image is a u32 pointer, but the vulnerable loop uses the 256-byte image_pitch as an element stride; a 63x64 copy writes controlled 252-byte rows at 1024-byte intervals far beyond the 16-KiB allocation, enabling control-flow hijacking.\nA:H - An excessive pitch can fault while reading beyond the TTM mapping, and the partial-copy destination bug can overwrite roughly 48 KiB beyond the snooper image, causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"db6fbc2b77849e3c3c2bc115ea9ac925c4625a0d","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"f6d9c8abdf06a9c7efa799532d66ed8d5a50734c","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"76e5ddd7d9822c8c3492e0f50ba8978e093069ad","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"fcb137f6e7ed769f7ecad84364a33c451371b602","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"21bc51cb89ced74d6645a138cc2f21184bc75094","versionType":"git"}],"programFiles":["drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.2"},{"status":"unaffected","version":"0","lessThan":"3.2","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:57.241Z","provider":"cve","references":["https://git.kernel.org/stable/c/db6fbc2b77849e3c3c2bc115ea9ac925c4625a0d","https://git.kernel.org/stable/c/f6d9c8abdf06a9c7efa799532d66ed8d5a50734c","https://git.kernel.org/stable/c/76e5ddd7d9822c8c3492e0f50ba8978e093069ad","https://git.kernel.org/stable/c/fcb137f6e7ed769f7ecad84364a33c451371b602","https://git.kernel.org/stable/c/21bc51cb89ced74d6645a138cc2f21184bc75094"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:57.241Z"}}},"related_cves":[{"value":"CVE-2026-99002","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:4554c98e-1467-4505-8a51-1e97fbf49bac","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99002","advisory_id":"4554c98e-1467-4505-8a51-1e97fbf49bac","event_types":["advisory"],"published_at":"2026-10-25T16:10:34.475267+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:22.763+00:00","detail_url":"/events/55727"},"members":[{"id":55727,"cve_ids":["CVE-2026-99002"],"payload":{"kind":"advisory","title":"drm/vmwgfx: validate pitch coming from userspace","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate pitch coming from userspace Validate the pitch, alongside the box dimensions before trying to copy data from the underlying surface. Fixes possible out of bounds reads with cursor snooping.","evidence":"cve:CVE-2026-99002","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-99002","aliases":["CVE-2026-99002"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - DRM_IOCTL_VMW_EXECBUF passes a locally supplied SVGA_3D_CMD_SURFACE_DMA through vmw_execbuf_process(), vmw_cmd_dma(), and vmw_kms_cursor_snoop(); the malformed guest.pitch and copy box originate in this ioctl, not a network protocol.\nAC:L - The attacker can create the required 64x64 A8R8G8B8 scanout surface and choose the box, pitch, and source BO. A 63x64 box with pitch 256 deterministically reaches the corrupting partial-copy loop without a race or attacker-uncontrolled condition.\nPR:L - VMW_CREATE_SURFACE, VMW_ALLOC_DMABUF, and VMW_EXECBUF are DRM_RENDER_ALLOW on a DRIVER_RENDER device; drm_ioctl_permit() therefore requires no DRM master, authentication, or capability from an unprivileged render-node client.\nUI:N - The attacker creates the surface and BO and submits the malformed DMA command through their own file descriptor; no victim must mount, open, or display anything.\nS:U - vmw_kms_cursor_snoop() corrupts the guest kernel's own cursor-snooper allocation from guest userspace. The code demonstrates neither host-memory corruption nor a guest-to-host or IOMMU-boundary escape.\nC:H - The unchecked pitch causes out-of-bounds source reads, while the attacker-controlled heap overwrite can corrupt neighboring pointer-bearing objects and be developed into arbitrary guest-kernel read primitives.\nI:H - snooper.image is a u32 pointer, but the vulnerable loop uses the 256-byte image_pitch as an element stride; a 63x64 copy writes controlled 252-byte rows at 1024-byte intervals far beyond the 16-KiB allocation, enabling control-flow hijacking.\nA:H - An excessive pitch can fault while reading beyond the TTM mapping, and the partial-copy destination bug can overwrite roughly 48 KiB beyond the snooper image, causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"db6fbc2b77849e3c3c2bc115ea9ac925c4625a0d","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"f6d9c8abdf06a9c7efa799532d66ed8d5a50734c","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"76e5ddd7d9822c8c3492e0f50ba8978e093069ad","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"fcb137f6e7ed769f7ecad84364a33c451371b602","versionType":"git"},{"status":"affected","version":"2ac863719e518ae1a8f328849e64ea26a222f079","lessThan":"21bc51cb89ced74d6645a138cc2f21184bc75094","versionType":"git"}],"programFiles":["drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"3.2"},{"status":"unaffected","version":"0","lessThan":"3.2","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/vmwgfx/vmwgfx_cursor_plane.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:57.241Z","provider":"cve","references":["https://git.kernel.org/stable/c/db6fbc2b77849e3c3c2bc115ea9ac925c4625a0d","https://git.kernel.org/stable/c/f6d9c8abdf06a9c7efa799532d66ed8d5a50734c","https://git.kernel.org/stable/c/76e5ddd7d9822c8c3492e0f50ba8978e093069ad","https://git.kernel.org/stable/c/fcb137f6e7ed769f7ecad84364a33c451371b602","https://git.kernel.org/stable/c/21bc51cb89ced74d6645a138cc2f21184bc75094"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:57.241Z"}}},"related_cves":[{"value":"CVE-2026-99002","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:4554c98e-1467-4505-8a51-1e97fbf49bac","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-99002","advisory_id":"4554c98e-1467-4505-8a51-1e97fbf49bac","event_types":["advisory"],"published_at":"2026-10-25T16:10:34.475267+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:22.763+00:00","detail_url":"/events/55727"}]}},{"id":56202,"cve_ids":["CVE-2026-98999"],"payload":{"kind":"advisory","title":"drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo's pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link. If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count > 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -> 0), it never touches pinned_link, leaving the bo linked on xe->pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced. The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue. Move the pinned_link removal into xe_bo_account_unpin(), which alread","evidence":"cve:CVE-2026-98999","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98999","aliases":["CVE-2026-98999"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local DRM ioctls reach patched xe_bo_account_unpin(): DRM_IOCTL_MODE_ATOMIC -> intel_atomic_commit -> intel_cleanup_plane_fb -> __xe_unpin_fb_vma -> xe_bo_unpin_account -> xe_bo_account_unpin; DRM_IOCTL_PRIME_FD_TO_HANDLE creates the competing pin through xe_dma_buf_pin().\nAC:L - On a hybrid-GPU host, one client can import the exported Xe BO, scan it out, close the import so xe_bo_unpin_external() runs at pin_count 2, disable the plane for the final fb unpin, free the BO, and pin another BO to touch the stale list. No race or independent actor is required.\nPR:L - XE_GEM_CREATE and both PRIME ioctls are DRM_RENDER_ALLOW; DRM_MODE_ATOMIC requires DRM_MASTER, but drm_master_open() makes the first primary-node opener master when none exists without CAP_SYS_ADMIN. An unprivileged user granted the DRM device nodes therefore suffices.\nUI:N - The same process issues the PRIME, atomic modeset/disable, and close operations; no victim must mount, open, or approve anything.\nS:U - The freed xe_bo and xe->pinned.late.external are kernel-owned objects, and xe_bo_apply_to_pinned() corrupts memory within the same host kernel; no guest/host, IOMMU, or other security authority is crossed.\nC:H - After xe_ttm_bo_destroy() frees an xe_bo still linked by pinned_link, xe_bo_apply_to_pinned() treats reclaimed slab contents as a live BO and eviction reads its resource, reservation, backup_obj, and flags pointers. This exploitable UAF supports arbitrary kernel-memory disclosure.\nI:H - xe_bo_apply_to_pinned() calls list_move_tail() on the freed pinned_link; after heap reclaim, its attacker-shaped prev/next pointers feed list deletion writes, enabling arbitrary kernel-memory corruption and potential control-flow hijacking.\nA:H - Reusing or walking xe->pinned.late.external after kfree(bo), through another xe_bo_pin_external() or xe_bo_apply_to_pinned(), dereferences and writes freed memory, corrupting the list and causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684","versionType":"git"},{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"b3eaff982839e5c22912d604cd8e7748cece8d63","versionType":"git"},{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"cf238c067eaae1cbfb00738e29219b9568d2313e","versionType":"git"}],"programFiles":["drivers/gpu/drm/xe/xe_bo.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.8"},{"status":"unaffected","version":"0","lessThan":"6.8","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/xe/xe_bo.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:56.167Z","provider":"cve","references":["https://git.kernel.org/stable/c/3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684","https://git.kernel.org/stable/c/b3eaff982839e5c22912d604cd8e7748cece8d63","https://git.kernel.org/stable/c/cf238c067eaae1cbfb00738e29219b9568d2313e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:56.167Z"}}},"related_cves":[{"value":"CVE-2026-98999","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98999","advisory_id":"2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","event_types":["advisory"],"published_at":"2026-10-25T16:10:33.631971+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:19.451+00:00","detail_url":"/advisories/advisory%3A2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","group":{"id":"advisory:2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","revision":1,"primary_event_id":55726,"change":"published","superseded_by":[],"changed":{"id":55726,"cve_ids":["CVE-2026-98999"],"payload":{"kind":"advisory","title":"drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo's pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link. If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count > 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -> 0), it never touches pinned_link, leaving the bo linked on xe->pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced. The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue. Move the pinned_link removal into xe_bo_account_unpin(), which alread","evidence":"cve:CVE-2026-98999","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98999","aliases":["CVE-2026-98999"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local DRM ioctls reach patched xe_bo_account_unpin(): DRM_IOCTL_MODE_ATOMIC -> intel_atomic_commit -> intel_cleanup_plane_fb -> __xe_unpin_fb_vma -> xe_bo_unpin_account -> xe_bo_account_unpin; DRM_IOCTL_PRIME_FD_TO_HANDLE creates the competing pin through xe_dma_buf_pin().\nAC:L - On a hybrid-GPU host, one client can import the exported Xe BO, scan it out, close the import so xe_bo_unpin_external() runs at pin_count 2, disable the plane for the final fb unpin, free the BO, and pin another BO to touch the stale list. No race or independent actor is required.\nPR:L - XE_GEM_CREATE and both PRIME ioctls are DRM_RENDER_ALLOW; DRM_MODE_ATOMIC requires DRM_MASTER, but drm_master_open() makes the first primary-node opener master when none exists without CAP_SYS_ADMIN. An unprivileged user granted the DRM device nodes therefore suffices.\nUI:N - The same process issues the PRIME, atomic modeset/disable, and close operations; no victim must mount, open, or approve anything.\nS:U - The freed xe_bo and xe->pinned.late.external are kernel-owned objects, and xe_bo_apply_to_pinned() corrupts memory within the same host kernel; no guest/host, IOMMU, or other security authority is crossed.\nC:H - After xe_ttm_bo_destroy() frees an xe_bo still linked by pinned_link, xe_bo_apply_to_pinned() treats reclaimed slab contents as a live BO and eviction reads its resource, reservation, backup_obj, and flags pointers. This exploitable UAF supports arbitrary kernel-memory disclosure.\nI:H - xe_bo_apply_to_pinned() calls list_move_tail() on the freed pinned_link; after heap reclaim, its attacker-shaped prev/next pointers feed list deletion writes, enabling arbitrary kernel-memory corruption and potential control-flow hijacking.\nA:H - Reusing or walking xe->pinned.late.external after kfree(bo), through another xe_bo_pin_external() or xe_bo_apply_to_pinned(), dereferences and writes freed memory, corrupting the list and causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684","versionType":"git"},{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"b3eaff982839e5c22912d604cd8e7748cece8d63","versionType":"git"},{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"cf238c067eaae1cbfb00738e29219b9568d2313e","versionType":"git"}],"programFiles":["drivers/gpu/drm/xe/xe_bo.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.8"},{"status":"unaffected","version":"0","lessThan":"6.8","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/xe/xe_bo.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:56.167Z","provider":"cve","references":["https://git.kernel.org/stable/c/3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684","https://git.kernel.org/stable/c/b3eaff982839e5c22912d604cd8e7748cece8d63","https://git.kernel.org/stable/c/cf238c067eaae1cbfb00738e29219b9568d2313e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:56.167Z"}}},"related_cves":[{"value":"CVE-2026-98999","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98999","advisory_id":"2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","event_types":["advisory"],"published_at":"2026-10-25T16:10:33.631971+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:19.451+00:00","detail_url":"/events/55726"},"members":[{"id":55726,"cve_ids":["CVE-2026-98999"],"payload":{"kind":"advisory","title":"drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin","summary":"In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo's pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link. If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count > 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -> 0), it never touches pinned_link, leaving the bo linked on xe->pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced. The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue. Move the pinned_link removal into xe_bo_account_unpin(), which alread","evidence":"cve:CVE-2026-98999","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98999","aliases":["CVE-2026-98999"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local DRM ioctls reach patched xe_bo_account_unpin(): DRM_IOCTL_MODE_ATOMIC -> intel_atomic_commit -> intel_cleanup_plane_fb -> __xe_unpin_fb_vma -> xe_bo_unpin_account -> xe_bo_account_unpin; DRM_IOCTL_PRIME_FD_TO_HANDLE creates the competing pin through xe_dma_buf_pin().\nAC:L - On a hybrid-GPU host, one client can import the exported Xe BO, scan it out, close the import so xe_bo_unpin_external() runs at pin_count 2, disable the plane for the final fb unpin, free the BO, and pin another BO to touch the stale list. No race or independent actor is required.\nPR:L - XE_GEM_CREATE and both PRIME ioctls are DRM_RENDER_ALLOW; DRM_MODE_ATOMIC requires DRM_MASTER, but drm_master_open() makes the first primary-node opener master when none exists without CAP_SYS_ADMIN. An unprivileged user granted the DRM device nodes therefore suffices.\nUI:N - The same process issues the PRIME, atomic modeset/disable, and close operations; no victim must mount, open, or approve anything.\nS:U - The freed xe_bo and xe->pinned.late.external are kernel-owned objects, and xe_bo_apply_to_pinned() corrupts memory within the same host kernel; no guest/host, IOMMU, or other security authority is crossed.\nC:H - After xe_ttm_bo_destroy() frees an xe_bo still linked by pinned_link, xe_bo_apply_to_pinned() treats reclaimed slab contents as a live BO and eviction reads its resource, reservation, backup_obj, and flags pointers. This exploitable UAF supports arbitrary kernel-memory disclosure.\nI:H - xe_bo_apply_to_pinned() calls list_move_tail() on the freed pinned_link; after heap reclaim, its attacker-shaped prev/next pointers feed list deletion writes, enabling arbitrary kernel-memory corruption and potential control-flow hijacking.\nA:H - Reusing or walking xe->pinned.late.external after kfree(bo), through another xe_bo_pin_external() or xe_bo_apply_to_pinned(), dereferences and writes freed memory, corrupting the list and causing an oops or kernel panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684","versionType":"git"},{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"b3eaff982839e5c22912d604cd8e7748cece8d63","versionType":"git"},{"status":"affected","version":"44e694958b95395bd1c41508c88c8ca141bf9bd7","lessThan":"cf238c067eaae1cbfb00738e29219b9568d2313e","versionType":"git"}],"programFiles":["drivers/gpu/drm/xe/xe_bo.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.8"},{"status":"unaffected","version":"0","lessThan":"6.8","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["drivers/gpu/drm/xe/xe_bo.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:56.167Z","provider":"cve","references":["https://git.kernel.org/stable/c/3a11adcfd9a2de74d405bd3e8c4d7a1b328e4684","https://git.kernel.org/stable/c/b3eaff982839e5c22912d604cd8e7748cece8d63","https://git.kernel.org/stable/c/cf238c067eaae1cbfb00738e29219b9568d2313e"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:56.167Z"}}},"related_cves":[{"value":"CVE-2026-98999","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98999","advisory_id":"2fa41e5e-9ef1-49a3-bb46-e85a76b3caec","event_types":["advisory"],"published_at":"2026-10-25T16:10:33.631971+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:19.451+00:00","detail_url":"/events/55726"}]}},{"id":56201,"cve_ids":["CVE-2026-98995"],"payload":{"kind":"advisory","title":"namespace: reset the old parent's ->overmount in mnt_change_mountpoint()","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: reset the old parent's ->overmount in mnt_change_mountpoint() __umount_mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it. For a mount that is moved beneath in attach_recursive_mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it. It matters for reparent() though. propagate_umount() moves a surviving overmount onto the first ancestor that isn't going to be unmounted. The mount it was taken from is unmounted immediately afterwards. If a file descriptor keeps that unmounted mount alive ->overmount points at the moved mount. That's a dangling pointer and UAF as the moved mount is unmounted and freed. do_lock_mount() follows ->overmount from the target path under mount_lock. With a file descriptor on such a mount as the target of a mount beneath topmost_overmount() walks into the freed mount and do_lock_mount() takes references on whatever it finds there. So reset ->overmount of the old parent in mnt_change_mountpoint() the same way __umount_mnt() does. A mount's ->overmount is then always a mount that is attached to it.","evidence":"cve:CVE-2026-98995","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98995","aliases":["CVE-2026-98995"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local umount2() reaches do_umount()->umount_tree()->propagate_umount()->reparent()->mnt_change_mountpoint(), and local move_mount(MOVE_MOUNT_BENEATH) later consumes the dangling overmount; no network or physical input reaches this path.\nAC:L - The regression test deterministically creates the propagation topology, pins X_b, frees its reparented overmount, and triggers the UAF; no race or external state is required, and any mount-cache grooming is attacker-controlled.\nPR:L - can_umount() and move_mount() require may_mount(), but the test's unshare(CLONE_NEWUSER|CLONE_NEWNS) gives an ordinary local user CAP_SYS_ADMIN in the child mount namespace, satisfying every mount-operation gate without init-namespace root.\nUI:N - The attacker personally creates the shared/private tmpfs mounts, opens the O_PATH descriptor, performs both lazy unmounts, and invokes move_mount(); no victim must mount, open, or otherwise act on anything.\nS:U - The dangling struct mount created by mnt_change_mountpoint() corrupts the same host kernel that enforces the attacker's mount namespace; this is ordinary kernel privilege escalation, not a VM, hypervisor, or IOMMU boundary crossing.\nC:H - topmost_overmount() reads freed struct mount contents, and where_to_mount() then consumes its stale overmount, mnt_mountpoint, and mnt_parent pointers; reclaiming the mnt_cache object permits redirected kernel-memory accesses and high-impact disclosure.\nI:H - do_lock_mount() calls mntget() and dget() through the freed mount-derived pointers, causing reference-count writes through stale mnt_pcp and dentry state; mount-cache reclamation and heap grooming can turn these UAF writes into control-flow corruption.\nA:H - Following the freed overmount and then dereferencing or locking the stale dentry->d_inode can produce a kernel UAF oops or panic, and the complete mount/unmount/move_mount sequence is repeatable by the same unprivileged process."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5","versionType":"git"},{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"08d575ee89393fd812dbdca7b5d7b4574cd5a564","versionType":"git"},{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"476ef286a7a5db8bda51325dc0c45887b4d99d9a","versionType":"git"}],"programFiles":["fs/namespace.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.17"},{"status":"unaffected","version":"0","lessThan":"6.17","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/namespace.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:55.095Z","provider":"cve","references":["https://git.kernel.org/stable/c/5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5","https://git.kernel.org/stable/c/08d575ee89393fd812dbdca7b5d7b4574cd5a564","https://git.kernel.org/stable/c/476ef286a7a5db8bda51325dc0c45887b4d99d9a"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:55.095Z"}}},"related_cves":[{"value":"CVE-2026-98995","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:72f5da3d-28b0-46f2-a2ae-959da8ed79e4","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98995","advisory_id":"72f5da3d-28b0-46f2-a2ae-959da8ed79e4","event_types":["advisory"],"published_at":"2026-10-25T16:10:32.831683+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:14.155+00:00","detail_url":"/advisories/advisory%3A72f5da3d-28b0-46f2-a2ae-959da8ed79e4","group":{"id":"advisory:72f5da3d-28b0-46f2-a2ae-959da8ed79e4","revision":1,"primary_event_id":55725,"change":"published","superseded_by":[],"changed":{"id":55725,"cve_ids":["CVE-2026-98995"],"payload":{"kind":"advisory","title":"namespace: reset the old parent's ->overmount in mnt_change_mountpoint()","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: reset the old parent's ->overmount in mnt_change_mountpoint() __umount_mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it. For a mount that is moved beneath in attach_recursive_mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it. It matters for reparent() though. propagate_umount() moves a surviving overmount onto the first ancestor that isn't going to be unmounted. The mount it was taken from is unmounted immediately afterwards. If a file descriptor keeps that unmounted mount alive ->overmount points at the moved mount. That's a dangling pointer and UAF as the moved mount is unmounted and freed. do_lock_mount() follows ->overmount from the target path under mount_lock. With a file descriptor on such a mount as the target of a mount beneath topmost_overmount() walks into the freed mount and do_lock_mount() takes references on whatever it finds there. So reset ->overmount of the old parent in mnt_change_mountpoint() the same way __umount_mnt() does. A mount's ->overmount is then always a mount that is attached to it.","evidence":"cve:CVE-2026-98995","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98995","aliases":["CVE-2026-98995"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local umount2() reaches do_umount()->umount_tree()->propagate_umount()->reparent()->mnt_change_mountpoint(), and local move_mount(MOVE_MOUNT_BENEATH) later consumes the dangling overmount; no network or physical input reaches this path.\nAC:L - The regression test deterministically creates the propagation topology, pins X_b, frees its reparented overmount, and triggers the UAF; no race or external state is required, and any mount-cache grooming is attacker-controlled.\nPR:L - can_umount() and move_mount() require may_mount(), but the test's unshare(CLONE_NEWUSER|CLONE_NEWNS) gives an ordinary local user CAP_SYS_ADMIN in the child mount namespace, satisfying every mount-operation gate without init-namespace root.\nUI:N - The attacker personally creates the shared/private tmpfs mounts, opens the O_PATH descriptor, performs both lazy unmounts, and invokes move_mount(); no victim must mount, open, or otherwise act on anything.\nS:U - The dangling struct mount created by mnt_change_mountpoint() corrupts the same host kernel that enforces the attacker's mount namespace; this is ordinary kernel privilege escalation, not a VM, hypervisor, or IOMMU boundary crossing.\nC:H - topmost_overmount() reads freed struct mount contents, and where_to_mount() then consumes its stale overmount, mnt_mountpoint, and mnt_parent pointers; reclaiming the mnt_cache object permits redirected kernel-memory accesses and high-impact disclosure.\nI:H - do_lock_mount() calls mntget() and dget() through the freed mount-derived pointers, causing reference-count writes through stale mnt_pcp and dentry state; mount-cache reclamation and heap grooming can turn these UAF writes into control-flow corruption.\nA:H - Following the freed overmount and then dereferencing or locking the stale dentry->d_inode can produce a kernel UAF oops or panic, and the complete mount/unmount/move_mount sequence is repeatable by the same unprivileged process."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5","versionType":"git"},{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"08d575ee89393fd812dbdca7b5d7b4574cd5a564","versionType":"git"},{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"476ef286a7a5db8bda51325dc0c45887b4d99d9a","versionType":"git"}],"programFiles":["fs/namespace.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.17"},{"status":"unaffected","version":"0","lessThan":"6.17","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/namespace.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:55.095Z","provider":"cve","references":["https://git.kernel.org/stable/c/5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5","https://git.kernel.org/stable/c/08d575ee89393fd812dbdca7b5d7b4574cd5a564","https://git.kernel.org/stable/c/476ef286a7a5db8bda51325dc0c45887b4d99d9a"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:55.095Z"}}},"related_cves":[{"value":"CVE-2026-98995","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:72f5da3d-28b0-46f2-a2ae-959da8ed79e4","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98995","advisory_id":"72f5da3d-28b0-46f2-a2ae-959da8ed79e4","event_types":["advisory"],"published_at":"2026-10-25T16:10:32.831683+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:14.155+00:00","detail_url":"/events/55725"},"members":[{"id":55725,"cve_ids":["CVE-2026-98995"],"payload":{"kind":"advisory","title":"namespace: reset the old parent's ->overmount in mnt_change_mountpoint()","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: reset the old parent's ->overmount in mnt_change_mountpoint() __umount_mnt() resets ->overmount of the parent when it unmounts the mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the mount to its new parent and leaves the old one pointing at it. For a mount that is moved beneath in attach_recursive_mnt() that doesn't matter. The new mount has already reset ->overmount of the old parent by the time the old top mount is moved onto it. It matters for reparent() though. propagate_umount() moves a surviving overmount onto the first ancestor that isn't going to be unmounted. The mount it was taken from is unmounted immediately afterwards. If a file descriptor keeps that unmounted mount alive ->overmount points at the moved mount. That's a dangling pointer and UAF as the moved mount is unmounted and freed. do_lock_mount() follows ->overmount from the target path under mount_lock. With a file descriptor on such a mount as the target of a mount beneath topmost_overmount() walks into the freed mount and do_lock_mount() takes references on whatever it finds there. So reset ->overmount of the old parent in mnt_change_mountpoint() the same way __umount_mnt() does. A mount's ->overmount is then always a mount that is attached to it.","evidence":"cve:CVE-2026-98995","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98995","aliases":["CVE-2026-98995"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local umount2() reaches do_umount()->umount_tree()->propagate_umount()->reparent()->mnt_change_mountpoint(), and local move_mount(MOVE_MOUNT_BENEATH) later consumes the dangling overmount; no network or physical input reaches this path.\nAC:L - The regression test deterministically creates the propagation topology, pins X_b, frees its reparented overmount, and triggers the UAF; no race or external state is required, and any mount-cache grooming is attacker-controlled.\nPR:L - can_umount() and move_mount() require may_mount(), but the test's unshare(CLONE_NEWUSER|CLONE_NEWNS) gives an ordinary local user CAP_SYS_ADMIN in the child mount namespace, satisfying every mount-operation gate without init-namespace root.\nUI:N - The attacker personally creates the shared/private tmpfs mounts, opens the O_PATH descriptor, performs both lazy unmounts, and invokes move_mount(); no victim must mount, open, or otherwise act on anything.\nS:U - The dangling struct mount created by mnt_change_mountpoint() corrupts the same host kernel that enforces the attacker's mount namespace; this is ordinary kernel privilege escalation, not a VM, hypervisor, or IOMMU boundary crossing.\nC:H - topmost_overmount() reads freed struct mount contents, and where_to_mount() then consumes its stale overmount, mnt_mountpoint, and mnt_parent pointers; reclaiming the mnt_cache object permits redirected kernel-memory accesses and high-impact disclosure.\nI:H - do_lock_mount() calls mntget() and dget() through the freed mount-derived pointers, causing reference-count writes through stale mnt_pcp and dentry state; mount-cache reclamation and heap grooming can turn these UAF writes into control-flow corruption.\nA:H - Following the freed overmount and then dereferencing or locking the stale dentry->d_inode can produce a kernel UAF oops or panic, and the complete mount/unmount/move_mount sequence is repeatable by the same unprivileged process."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5","versionType":"git"},{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"08d575ee89393fd812dbdca7b5d7b4574cd5a564","versionType":"git"},{"status":"affected","version":"ffdc52fbbd5835a936ad683c943d6d103a2d4514","lessThan":"476ef286a7a5db8bda51325dc0c45887b4d99d9a","versionType":"git"}],"programFiles":["fs/namespace.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.17"},{"status":"unaffected","version":"0","lessThan":"6.17","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/namespace.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:55.095Z","provider":"cve","references":["https://git.kernel.org/stable/c/5e0a1f2c753a79749bc2ead3ae2f2ede3941daa5","https://git.kernel.org/stable/c/08d575ee89393fd812dbdca7b5d7b4574cd5a564","https://git.kernel.org/stable/c/476ef286a7a5db8bda51325dc0c45887b4d99d9a"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:55.095Z"}}},"related_cves":[{"value":"CVE-2026-98995","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:72f5da3d-28b0-46f2-a2ae-959da8ed79e4","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98995","advisory_id":"72f5da3d-28b0-46f2-a2ae-959da8ed79e4","event_types":["advisory"],"published_at":"2026-10-25T16:10:32.831683+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:14.155+00:00","detail_url":"/events/55725"}]}},{"id":56200,"cve_ids":["CVE-2026-98993"],"payload":{"kind":"advisory","title":"namespace: don't inherit MNT_UMOUNT in clone_mnt()","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source and only masks MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was lazily unmounted but is kept alive by a file descriptor can still be copied when its root is an nsfs or pidfs file because may_copy_tree() accepts those before checking whether the source is mounted at all: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --bind /proc/self/fd/3 /tmp/y The mount on /tmp/y is attached to the caller's namespace with MNT_UMOUNT already set and every copy of it inherits the flag again. That causes a number of bugs: - Unlink its mountpoint from a mount namespace where it isn't one. __detach_mounts() takes it for a mount that was unmounted earlier, unhooks it from its parent and drops the reference the namespace holds on it. It stays in the namespace with one reference too few and as its own parent, so it","evidence":"cve:CVE-2026-98993","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98993","aliases":["CVE-2026-98993"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - mount(2) reaches path_mount()->do_loopback()->__do_loopback()->clone_mnt(), which copies MNT_UMOUNT from an fd-pinned, lazily unmounted nsfs/pidfs mount; the causal operations are local syscalls.\nAC:L - The attacker can deterministically bind an nsfs/pidfs file, retain an fd, call umount2(MNT_DETACH), rebind /proc/self/fd/N, and unlink the mountpoint from an attacker-controlled sibling mount namespace; no uncontrollable race is required.\nPR:L - path_mount() and can_umount() use may_mount(), which checks CAP_SYS_ADMIN in the mount namespace's owning user namespace; an unprivileged user can obtain that capability with unshare(CLONE_NEWUSER|CLONE_NEWNS).\nUI:N - The attacker performs the namespace creation, bind mounts, lazy unmount, fd retention, and unlink operations without any victim action.\nS:U - clone_mnt() corrupts mount and mnt_namespace lifetime state within the same host kernel security authority; a resulting local kernel privilege escalation remains scope unchanged.\nC:H - __detach_mounts() leaves the fd-pinned mount's mnt_ns pointing to a freed struct mnt_namespace; may_change_propagation() dereferences its freed user_ns and anon_ns_root() reads freed namespace fields, creating an attacker-triggered kernel UAF.\nI:H - After the dangling mnt_ns passes may_change_propagation(), do_change_type() calls touch_mnt_namespace(), which writes ns->event and operates on ns->poll through freed, reclaimable storage, supporting heap corruption and control-flow exploitation.\nA:H - reparent() can loop forever on the self-parented unmounted chain, umount_tree() can visit a child twice, and the dangling namespace accesses can fault, permitting a kernel hang or crash."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"99698cfa34e493fc091219056aae446fe9442a96","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"c26c1a91ad2881a194f7af543e0b57f0870006b2","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"eecc9cd0fc07dba3f7fb0b2f844b4029435a2f7b","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"5077b52e9e4d72da53c50251296b99cd416765a1","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"e2c6d326216642011da318b9edfd5d57ebd5a56f","versionType":"git"},{"status":"affected","version":"7052e71b2d085f76800115d4a212dcaf82b86262","versionType":"git"},{"status":"affected","version":"4.0.2","lessThan":"4.1","versionType":"semver"}],"programFiles":["fs/namespace.c","include/linux/mount.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.1"},{"status":"unaffected","version":"0","lessThan":"4.1","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/namespace.c","include/linux/mount.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:54.039Z","provider":"cve","references":["https://git.kernel.org/stable/c/99698cfa34e493fc091219056aae446fe9442a96","https://git.kernel.org/stable/c/c26c1a91ad2881a194f7af543e0b57f0870006b2","https://git.kernel.org/stable/c/eecc9cd0fc07dba3f7fb0b2f844b4029435a2f7b","https://git.kernel.org/stable/c/5077b52e9e4d72da53c50251296b99cd416765a1","https://git.kernel.org/stable/c/e2c6d326216642011da318b9edfd5d57ebd5a56f"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:54.039Z"}}},"related_cves":[{"value":"CVE-2026-98993","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:032a07f2-5e4f-4551-b0e6-074bbfe066e9","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98993","advisory_id":"032a07f2-5e4f-4551-b0e6-074bbfe066e9","event_types":["advisory"],"published_at":"2026-10-25T16:10:32.155319+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:12.266+00:00","detail_url":"/advisories/advisory%3A032a07f2-5e4f-4551-b0e6-074bbfe066e9","group":{"id":"advisory:032a07f2-5e4f-4551-b0e6-074bbfe066e9","revision":1,"primary_event_id":55724,"change":"published","superseded_by":[],"changed":{"id":55724,"cve_ids":["CVE-2026-98993"],"payload":{"kind":"advisory","title":"namespace: don't inherit MNT_UMOUNT in clone_mnt()","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source and only masks MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was lazily unmounted but is kept alive by a file descriptor can still be copied when its root is an nsfs or pidfs file because may_copy_tree() accepts those before checking whether the source is mounted at all: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --bind /proc/self/fd/3 /tmp/y The mount on /tmp/y is attached to the caller's namespace with MNT_UMOUNT already set and every copy of it inherits the flag again. That causes a number of bugs: - Unlink its mountpoint from a mount namespace where it isn't one. __detach_mounts() takes it for a mount that was unmounted earlier, unhooks it from its parent and drops the reference the namespace holds on it. It stays in the namespace with one reference too few and as its own parent, so it","evidence":"cve:CVE-2026-98993","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98993","aliases":["CVE-2026-98993"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - mount(2) reaches path_mount()->do_loopback()->__do_loopback()->clone_mnt(), which copies MNT_UMOUNT from an fd-pinned, lazily unmounted nsfs/pidfs mount; the causal operations are local syscalls.\nAC:L - The attacker can deterministically bind an nsfs/pidfs file, retain an fd, call umount2(MNT_DETACH), rebind /proc/self/fd/N, and unlink the mountpoint from an attacker-controlled sibling mount namespace; no uncontrollable race is required.\nPR:L - path_mount() and can_umount() use may_mount(), which checks CAP_SYS_ADMIN in the mount namespace's owning user namespace; an unprivileged user can obtain that capability with unshare(CLONE_NEWUSER|CLONE_NEWNS).\nUI:N - The attacker performs the namespace creation, bind mounts, lazy unmount, fd retention, and unlink operations without any victim action.\nS:U - clone_mnt() corrupts mount and mnt_namespace lifetime state within the same host kernel security authority; a resulting local kernel privilege escalation remains scope unchanged.\nC:H - __detach_mounts() leaves the fd-pinned mount's mnt_ns pointing to a freed struct mnt_namespace; may_change_propagation() dereferences its freed user_ns and anon_ns_root() reads freed namespace fields, creating an attacker-triggered kernel UAF.\nI:H - After the dangling mnt_ns passes may_change_propagation(), do_change_type() calls touch_mnt_namespace(), which writes ns->event and operates on ns->poll through freed, reclaimable storage, supporting heap corruption and control-flow exploitation.\nA:H - reparent() can loop forever on the self-parented unmounted chain, umount_tree() can visit a child twice, and the dangling namespace accesses can fault, permitting a kernel hang or crash."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"99698cfa34e493fc091219056aae446fe9442a96","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"c26c1a91ad2881a194f7af543e0b57f0870006b2","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"eecc9cd0fc07dba3f7fb0b2f844b4029435a2f7b","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"5077b52e9e4d72da53c50251296b99cd416765a1","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"e2c6d326216642011da318b9edfd5d57ebd5a56f","versionType":"git"},{"status":"affected","version":"7052e71b2d085f76800115d4a212dcaf82b86262","versionType":"git"},{"status":"affected","version":"4.0.2","lessThan":"4.1","versionType":"semver"}],"programFiles":["fs/namespace.c","include/linux/mount.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.1"},{"status":"unaffected","version":"0","lessThan":"4.1","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/namespace.c","include/linux/mount.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:54.039Z","provider":"cve","references":["https://git.kernel.org/stable/c/99698cfa34e493fc091219056aae446fe9442a96","https://git.kernel.org/stable/c/c26c1a91ad2881a194f7af543e0b57f0870006b2","https://git.kernel.org/stable/c/eecc9cd0fc07dba3f7fb0b2f844b4029435a2f7b","https://git.kernel.org/stable/c/5077b52e9e4d72da53c50251296b99cd416765a1","https://git.kernel.org/stable/c/e2c6d326216642011da318b9edfd5d57ebd5a56f"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:54.039Z"}}},"related_cves":[{"value":"CVE-2026-98993","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:032a07f2-5e4f-4551-b0e6-074bbfe066e9","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98993","advisory_id":"032a07f2-5e4f-4551-b0e6-074bbfe066e9","event_types":["advisory"],"published_at":"2026-10-25T16:10:32.155319+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:12.266+00:00","detail_url":"/events/55724"},"members":[{"id":55724,"cve_ids":["CVE-2026-98993"],"payload":{"kind":"advisory","title":"namespace: don't inherit MNT_UMOUNT in clone_mnt()","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source and only masks MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was lazily unmounted but is kept alive by a file descriptor can still be copied when its root is an nsfs or pidfs file because may_copy_tree() accepts those before checking whether the source is mounted at all: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x mount --bind /proc/self/fd/3 /tmp/y The mount on /tmp/y is attached to the caller's namespace with MNT_UMOUNT already set and every copy of it inherits the flag again. That causes a number of bugs: - Unlink its mountpoint from a mount namespace where it isn't one. __detach_mounts() takes it for a mount that was unmounted earlier, unhooks it from its parent and drops the reference the namespace holds on it. It stays in the namespace with one reference too few and as its own parent, so it","evidence":"cve:CVE-2026-98993","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98993","aliases":["CVE-2026-98993"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - mount(2) reaches path_mount()->do_loopback()->__do_loopback()->clone_mnt(), which copies MNT_UMOUNT from an fd-pinned, lazily unmounted nsfs/pidfs mount; the causal operations are local syscalls.\nAC:L - The attacker can deterministically bind an nsfs/pidfs file, retain an fd, call umount2(MNT_DETACH), rebind /proc/self/fd/N, and unlink the mountpoint from an attacker-controlled sibling mount namespace; no uncontrollable race is required.\nPR:L - path_mount() and can_umount() use may_mount(), which checks CAP_SYS_ADMIN in the mount namespace's owning user namespace; an unprivileged user can obtain that capability with unshare(CLONE_NEWUSER|CLONE_NEWNS).\nUI:N - The attacker performs the namespace creation, bind mounts, lazy unmount, fd retention, and unlink operations without any victim action.\nS:U - clone_mnt() corrupts mount and mnt_namespace lifetime state within the same host kernel security authority; a resulting local kernel privilege escalation remains scope unchanged.\nC:H - __detach_mounts() leaves the fd-pinned mount's mnt_ns pointing to a freed struct mnt_namespace; may_change_propagation() dereferences its freed user_ns and anon_ns_root() reads freed namespace fields, creating an attacker-triggered kernel UAF.\nI:H - After the dangling mnt_ns passes may_change_propagation(), do_change_type() calls touch_mnt_namespace(), which writes ns->event and operates on ns->poll through freed, reclaimable storage, supporting heap corruption and control-flow exploitation.\nA:H - reparent() can loop forever on the self-parented unmounted chain, umount_tree() can visit a child twice, and the dangling namespace accesses can fault, permitting a kernel hang or crash."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"99698cfa34e493fc091219056aae446fe9442a96","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"c26c1a91ad2881a194f7af543e0b57f0870006b2","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"eecc9cd0fc07dba3f7fb0b2f844b4029435a2f7b","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"5077b52e9e4d72da53c50251296b99cd416765a1","versionType":"git"},{"status":"affected","version":"590ce4bcbfb4e0462a720a4ad901e84416080bba","lessThan":"e2c6d326216642011da318b9edfd5d57ebd5a56f","versionType":"git"},{"status":"affected","version":"7052e71b2d085f76800115d4a212dcaf82b86262","versionType":"git"},{"status":"affected","version":"4.0.2","lessThan":"4.1","versionType":"semver"}],"programFiles":["fs/namespace.c","include/linux/mount.h"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"4.1"},{"status":"unaffected","version":"0","lessThan":"4.1","versionType":"semver"},{"status":"unaffected","version":"6.6.160","versionType":"semver","lessThanOrEqual":"6.6.*"},{"status":"unaffected","version":"6.12.114","versionType":"semver","lessThanOrEqual":"6.12.*"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/namespace.c","include/linux/mount.h"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:54.039Z","provider":"cve","references":["https://git.kernel.org/stable/c/99698cfa34e493fc091219056aae446fe9442a96","https://git.kernel.org/stable/c/c26c1a91ad2881a194f7af543e0b57f0870006b2","https://git.kernel.org/stable/c/eecc9cd0fc07dba3f7fb0b2f844b4029435a2f7b","https://git.kernel.org/stable/c/5077b52e9e4d72da53c50251296b99cd416765a1","https://git.kernel.org/stable/c/e2c6d326216642011da318b9edfd5d57ebd5a56f"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:54.039Z"}}},"related_cves":[{"value":"CVE-2026-98993","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:032a07f2-5e4f-4551-b0e6-074bbfe066e9","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98993","advisory_id":"032a07f2-5e4f-4551-b0e6-074bbfe066e9","event_types":["advisory"],"published_at":"2026-10-25T16:10:32.155319+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:12.266+00:00","detail_url":"/events/55724"}]}},{"id":56199,"cve_ids":["CVE-2026-98991"],"payload":{"kind":"advisory","title":"namespace: queue a mount only once for mount notifications","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: queue a mount only once for mount notifications mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't. propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time. The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40 This needs a mount with MNT_SHRINKABLE to bind from. That's what finish_automount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace wit","evidence":"cve:CVE-2026-98991","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98991","aliases":["CVE-2026-98991"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local umount(2) follows ksys_umount()->path_umount()->do_umount()->shrink_submounts()->umount_tree()->propagate_umount()->reparent()->mnt_notify_add(), the function patched; no network protocol supplies the triggering mount topology.\nAC:L - With a reachable MNT_SHRINKABLE automount, the attacker can create the required bind, shared/slave, and overmount topology and synchronously unmount it; duplicate queueing occurs sequentially under one namespace_sem hold and requires no race.\nPR:L - may_mount() and FAN_MARK_MNTNS use CAP_SYS_ADMIN relative to the attacker-owned mount/group/target user namespaces; unshare(CLONE_NEWUSER|CLONE_NEWNS) gives an ordinary local user those namespace-scoped capabilities without init-namespace privilege.\nUI:N - The attacker personally creates the fanotify mark and mount topology and invokes umount(2); no victim must mount media, open a file, or perform another action.\nS:U - The corrupted global notify_list and freed struct mount objects are resources of the same host kernel reached by the attacker; this is a kernel privilege-escalation boundary, not a guest-host, IOMMU, or other scope change.\nC:H - notify_mnt_list() leaves notify_list linked through freed struct mount::to_notify nodes, so later mount operations dereference attacker-reclaimable mnt_cache objects; this kernel-heap UAF can be leveraged to disclose kernel memory.\nI:H - After the stale to_notify node is freed or reallocated, __list_add() in mnt_notify_add() writes next->prev and prev->next through the corrupted list links, providing exploitable kernel-heap corruption capable of control-flow hijacking.\nA:H - namespace_unlock() frees mounts still referenced by notify_list, and a later path_mount()->mnt_add_to_ns()->mnt_notify_add() provably reads the freed node, producing the documented KASAN slab-use-after-free and a host kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"acbe9e4418e2ef7bef1a12e62e0e7d6145a15190","versionType":"git"},{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"702ff3fe499876e09c45558a05366d21a5bc41ab","versionType":"git"},{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"bd2feb7796b6585938a4241e7b7c4148a6f7b762","versionType":"git"}],"programFiles":["fs/mount.h","fs/namespace.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.15"},{"status":"unaffected","version":"0","lessThan":"6.15","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/mount.h","fs/namespace.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:52.901Z","provider":"cve","references":["https://git.kernel.org/stable/c/acbe9e4418e2ef7bef1a12e62e0e7d6145a15190","https://git.kernel.org/stable/c/702ff3fe499876e09c45558a05366d21a5bc41ab","https://git.kernel.org/stable/c/bd2feb7796b6585938a4241e7b7c4148a6f7b762"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:52.901Z"}}},"related_cves":[{"value":"CVE-2026-98991","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:cff2024a-8d28-4bb6-97c4-ca823dced7ba","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98991","advisory_id":"cff2024a-8d28-4bb6-97c4-ca823dced7ba","event_types":["advisory"],"published_at":"2026-10-25T16:10:31.432335+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:10.289+00:00","detail_url":"/advisories/advisory%3Acff2024a-8d28-4bb6-97c4-ca823dced7ba","group":{"id":"advisory:cff2024a-8d28-4bb6-97c4-ca823dced7ba","revision":1,"primary_event_id":55723,"change":"published","superseded_by":[],"changed":{"id":55723,"cve_ids":["CVE-2026-98991"],"payload":{"kind":"advisory","title":"namespace: queue a mount only once for mount notifications","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: queue a mount only once for mount notifications mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't. propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time. The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40 This needs a mount with MNT_SHRINKABLE to bind from. That's what finish_automount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace wit","evidence":"cve:CVE-2026-98991","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98991","aliases":["CVE-2026-98991"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local umount(2) follows ksys_umount()->path_umount()->do_umount()->shrink_submounts()->umount_tree()->propagate_umount()->reparent()->mnt_notify_add(), the function patched; no network protocol supplies the triggering mount topology.\nAC:L - With a reachable MNT_SHRINKABLE automount, the attacker can create the required bind, shared/slave, and overmount topology and synchronously unmount it; duplicate queueing occurs sequentially under one namespace_sem hold and requires no race.\nPR:L - may_mount() and FAN_MARK_MNTNS use CAP_SYS_ADMIN relative to the attacker-owned mount/group/target user namespaces; unshare(CLONE_NEWUSER|CLONE_NEWNS) gives an ordinary local user those namespace-scoped capabilities without init-namespace privilege.\nUI:N - The attacker personally creates the fanotify mark and mount topology and invokes umount(2); no victim must mount media, open a file, or perform another action.\nS:U - The corrupted global notify_list and freed struct mount objects are resources of the same host kernel reached by the attacker; this is a kernel privilege-escalation boundary, not a guest-host, IOMMU, or other scope change.\nC:H - notify_mnt_list() leaves notify_list linked through freed struct mount::to_notify nodes, so later mount operations dereference attacker-reclaimable mnt_cache objects; this kernel-heap UAF can be leveraged to disclose kernel memory.\nI:H - After the stale to_notify node is freed or reallocated, __list_add() in mnt_notify_add() writes next->prev and prev->next through the corrupted list links, providing exploitable kernel-heap corruption capable of control-flow hijacking.\nA:H - namespace_unlock() frees mounts still referenced by notify_list, and a later path_mount()->mnt_add_to_ns()->mnt_notify_add() provably reads the freed node, producing the documented KASAN slab-use-after-free and a host kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"acbe9e4418e2ef7bef1a12e62e0e7d6145a15190","versionType":"git"},{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"702ff3fe499876e09c45558a05366d21a5bc41ab","versionType":"git"},{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"bd2feb7796b6585938a4241e7b7c4148a6f7b762","versionType":"git"}],"programFiles":["fs/mount.h","fs/namespace.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.15"},{"status":"unaffected","version":"0","lessThan":"6.15","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/mount.h","fs/namespace.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:52.901Z","provider":"cve","references":["https://git.kernel.org/stable/c/acbe9e4418e2ef7bef1a12e62e0e7d6145a15190","https://git.kernel.org/stable/c/702ff3fe499876e09c45558a05366d21a5bc41ab","https://git.kernel.org/stable/c/bd2feb7796b6585938a4241e7b7c4148a6f7b762"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:52.901Z"}}},"related_cves":[{"value":"CVE-2026-98991","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:cff2024a-8d28-4bb6-97c4-ca823dced7ba","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98991","advisory_id":"cff2024a-8d28-4bb6-97c4-ca823dced7ba","event_types":["advisory"],"published_at":"2026-10-25T16:10:31.432335+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:10.289+00:00","detail_url":"/events/55723"},"members":[{"id":55723,"cve_ids":["CVE-2026-98991"],"payload":{"kind":"advisory","title":"namespace: queue a mount only once for mount notifications","summary":"In the Linux kernel, the following vulnerability has been resolved: namespace: queue a mount only once for mount notifications mnt_notify_add() puts a mount on notify_list. It doesn't check whether the mount is on the list already. That's fine as long as every mount is queued at most once per namespace_sem hold. It isn't. propagate_umount() moves a surviving overmount off a stack of mounts that are going away and queues it as moved. shrink_submounts() and mark_mounts_for_expiry() call umount_tree() for several mounts under a single namespace_sem hold. So the second umount_tree() can take down exactly the mount the first one reparented, reparent it once more and so end up queueing it a second time. The second list_add_tail() cuts the mounts queued in between out of the list while the head still points at the last of them. notify_mnt_list() then only visits that one mount and the others are freed after the grace period with notify_list still pointing at them. Every later mount operation on the host walks freed memory: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report Read of size 8 at addr ffff8881003d57e0 by task notify_dq/162 __list_add_valid_or_report+0x15c/0x1a0 mnt_add_to_ns+0x322/0x890 attach_recursive_mnt.isra.0+0xf2a/0x1a00 path_mount+0x139c/0x1d40 This needs a mount with MNT_SHRINKABLE to bind from. That's what finish_automount() creates (submounts of NFS, AFS and CIFS and the tracefs mount below debugfs). Bind mounts inherit the flag. A mount namespace wit","evidence":"cve:CVE-2026-98991","products":[{"name":{"value":"Linux","evidence":"/containers/cna/affected/0/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]},{"name":{"value":"Linux","evidence":"/containers/cna/affected/1/product"},"prerequisites":[],"fixed_versions":[],"affected_versions":[]}],"severity":"high","structured":{"id":"CVE-2026-98991","aliases":["CVE-2026-98991"],"metrics":[{"cvssV3_1":{"version":"3.1","baseScore":7.8,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"scenarios":[{"lang":"en","value":"AV:L - Local umount(2) follows ksys_umount()->path_umount()->do_umount()->shrink_submounts()->umount_tree()->propagate_umount()->reparent()->mnt_notify_add(), the function patched; no network protocol supplies the triggering mount topology.\nAC:L - With a reachable MNT_SHRINKABLE automount, the attacker can create the required bind, shared/slave, and overmount topology and synchronously unmount it; duplicate queueing occurs sequentially under one namespace_sem hold and requires no race.\nPR:L - may_mount() and FAN_MARK_MNTNS use CAP_SYS_ADMIN relative to the attacker-owned mount/group/target user namespaces; unshare(CLONE_NEWUSER|CLONE_NEWNS) gives an ordinary local user those namespace-scoped capabilities without init-namespace privilege.\nUI:N - The attacker personally creates the fanotify mark and mount topology and invokes umount(2); no victim must mount media, open a file, or perform another action.\nS:U - The corrupted global notify_list and freed struct mount objects are resources of the same host kernel reached by the attacker; this is a kernel privilege-escalation boundary, not a guest-host, IOMMU, or other scope change.\nC:H - notify_mnt_list() leaves notify_list linked through freed struct mount::to_notify nodes, so later mount operations dereference attacker-reclaimable mnt_cache objects; this kernel-heap UAF can be leveraged to disclose kernel memory.\nI:H - After the stale to_notify node is freed or reallocated, __list_add() in mnt_notify_add() writes next->prev and prev->next through the corrupted list links, providing exploitable kernel-heap corruption capable of control-flow hijacking.\nA:H - namespace_unlock() frees mounts still referenced by notify_list, and a later path_mount()->mnt_add_to_ns()->mnt_notify_add() provably reads the freed node, producing the documented KASAN slab-use-after-free and a host kernel oops or panic."}]}],"affected":[{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"acbe9e4418e2ef7bef1a12e62e0e7d6145a15190","versionType":"git"},{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"702ff3fe499876e09c45558a05366d21a5bc41ab","versionType":"git"},{"status":"affected","version":"bf630c40164162ba1d3933c2f5e3397d083e0948","lessThan":"bd2feb7796b6585938a4241e7b7c4148a6f7b762","versionType":"git"}],"programFiles":["fs/mount.h","fs/namespace.c"],"defaultStatus":"unaffected"},{"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","product":"Linux","versions":[{"status":"affected","version":"6.15"},{"status":"unaffected","version":"0","lessThan":"6.15","versionType":"semver"},{"status":"unaffected","version":"6.18.57","versionType":"semver","lessThanOrEqual":"6.18.*"},{"status":"unaffected","version":"7.2.11","versionType":"semver","lessThanOrEqual":"7.2.*"},{"status":"unaffected","version":"7.3","versionType":"original_commit_for_fix","lessThanOrEqual":"*"}],"programFiles":["fs/mount.h","fs/namespace.c"],"defaultStatus":"affected"}],"modified":"2026-10-24T14:09:52.901Z","provider":"cve","references":["https://git.kernel.org/stable/c/acbe9e4418e2ef7bef1a12e62e0e7d6145a15190","https://git.kernel.org/stable/c/702ff3fe499876e09c45558a05366d21a5bc41ab","https://git.kernel.org/stable/c/bd2feb7796b6585938a4241e7b7c4148a6f7b762"],"provider_metadata":{"cna":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-10-24T14:09:52.901Z"}}},"related_cves":[{"value":"CVE-2026-98991","evidence":"/cveMetadata/cveId"}],"security_relevant":true,"severity_evidence":"/containers/cna/metrics"},"group_id":"advisory:cff2024a-8d28-4bb6-97c4-ca823dced7ba","priority":{"reasons":["publisher_severity"],"severity":"high","linked_cves":[],"fix_available":false,"known_exploited":false,"publisher_severity":"high"},"revision":1,"source_id":"core-cve","source_url":"https://www.cve.org/CVERecord?id=CVE-2026-98991","advisory_id":"cff2024a-8d28-4bb6-97c4-ca823dced7ba","event_types":["advisory"],"published_at":"2026-10-25T16:10:31.432335+00:00","technologies":["core-cve","linux"],"context_update":false,"extraction_method":"structured","source_published_at":"2026-10-23T12:20:10.289+00:00","detail_url":"/events/55723"}]}}],"next_after":56228,"next_before":56199}