CVE-2026-64232 Affecting kernel-azure-vdso package, versions <6.12.0-160000.38.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES1600-KERNELAZUREVDSO-20315224
- published30 Sept 2026
- disclosed22 Sept 2026
Introduced: 22 Sep 2026
NewCVE-2026-64232 (opens in a new tab)How to fix?
Upgrade SLES:16.0.0 kernel-azure-vdso to version 6.12.0-160000.38.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-azure-vdso package and not the kernel-azure-vdso package as distributed by SLES.
See How to fix? for SLES:16.0.0 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
block: recompute nr_integrity_segments in blk_insert_cloned_request
blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virt_boundary_mask, seg_boundary_mask, or max_segment_size than the top queue, in which case blk_rq_count_integrity_sg() against the bottom queue produces a different count than the cached rq->nr_integrity_segments inherited from the source request by blk_rq_prep_clone().
When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips
BUG_ON(segments > rq->nr_integrity_segments);
on dispatch. The same families of stacked setups that motivated the existing nr_phys_segments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this.
Mirror the nr_phys_segments handling: when the request carries integrity, recompute nr_integrity_segments against the bottom queue and reject the request if it exceeds the bottom queue's max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes.
This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
References
- https://www.suse.com/security/cve/CVE-2026-64232.html
- https://bugzilla.suse.com/1272791
- https://git.kernel.org/stable/c/0943f81e1b3176f27dbaf6db268fc69d8a94f0ba
- https://git.kernel.org/stable/c/2c6e6a18a37b905cb584eb0dda3ae482162a81ca
- https://git.kernel.org/stable/c/42929c98d044f126508baf54a65b0f87f932fa75
- https://git.kernel.org/stable/c/53a01bcc0242590eda4c452a5bd996f62457113b