Look up another CVE · open CVE-2026-64053 in the interactive tracker
CVE-2026-64053
block: don't overwrite bip_vcnt in bio_integrity_copy_user()
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem block. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64053 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
bio_integrity_add_page() already sets bip_vcnt to 1 for the bounce segment. Overwriting it with nr_vecs breaks bip_vcnt <= bip_max_vcnt on WRITE (bip_max_vcnt is 1), so the gap-merge checks in block/blk.h read past the bip_vec[] flex array. On READ the read is in bounds but lands on a saved user bvec instead of the bounce. The line was added for split propagation, but bio_integrity_clone() doesn't copy bip_vcnt and BIP_CLONE_FLAGS excludes BIP_COPY_USER.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
block/bio-integrity.c
- What this is
- BLOCK LAYERMAINTAINERS section matched on block/ · linux-block@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_BLK_DEV_INTEGRITY /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_BLK_DEV_INTEGRITY
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- block
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.11 | 6.12.92 | d18160c9525c |
| 6.11 | 6.18.34 | 0d48654af4d1 |
| 6.11 | 7.0.11 | 066be1439593 |
| 6.11 | 7.1 | 637ad3a56a3b |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is only reachable via local syscalls on an integrity-capable block device—io_uring read/write with PI attributes (`IOCB_HAS_METADATA` → `bio_integrity_map_iter()`) or NVMe ioctls (`NVME_IOCTL_SUBMIT_IO`/`NVME_IOCTL_IO_CMD` → `blk_rq_integrity_map_user()`). No network-facing server path (ksmbd, nfsd, nvmet) calls `bio_integrity_copy_user()`.
- AC:LAttack complexity, low
- An attacker fully controls the conditions needed to hit the copy path and trigger the bad index: misaligned or multi-segment integrity user buffers force `copy=true`, multi-page scatter yields `nr_bvecs>1`, and concurrent O_DIRECT integrity writes to the same queue trigger `integrity_req_gap_*_merge()` that dereferences the corrupted `bip_vcnt`.
- PR:LPrivileges required, low
- No kernel capabilities or init-namespace root are required beyond permission to open and perform O_DIRECT I/O on an integrity-enabled block device (`/dev/nvme*`, SCSI DIF disk); io_uring and NVMe ioctls are available to any local user granted device access (e.g., disk group, container volume mounts on storage nodes).
- UI:NUser interaction, none
- Exploitation is self-initiated by the attacker issuing crafted integrity I/O; no victim interaction such as mounting a filesystem or opening a file is required.
- S:UScope, unchanged
- Impact is confined to kernel memory safety within the block-integrity path on the host; it does not cross a VM, IOMMU, or sandbox security boundary.
- C:HConfidentiality impact, high
- On WRITE, `bip_vcnt` is incorrectly set to `nr_vecs` while `bip_max_vcnt` is 1, so `integrity_req_gap_back_merge()`/`integrity_req_gap_front_merge()` in `block/blk.h` index `bip_vec[bip_vcnt-1]` past the single-slot kmalloc flex array, causing an out-of-bounds read of adjacent kernel heap memory that can disclose kernel pointers and other sensitive data.
- I:HIntegrity impact, high
- The corrupted `bip_vcnt` breaks integrity metadata bookkeeping during bio/request merging; on READ it causes gap-merge logic to consult saved user bvecs instead of the kernel bounce buffer, and the heap OOB read corrupts kernel memory-safety invariants in ways that can be chained toward further memory corruption or control-flow manipulation.
- A:HAvailability impact, high
- With large `nr_bvecs` (up to `BIO_MAX_VECS`), the out-of-bounds `bip_vec` access can extend far beyond the kmalloc object boundary and provoke a kernel oops/page fault during merge processing; even without full exploitation, the integrity path malfunction can destabilize the I/O stack.