block: recompute nr_integrity_segments in blk_insert_cloned_request
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 , 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 account
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.92, 6.18.34, 7.0.11
- CVEs
- CVE-2026-64232
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 7 Nov 2026, 13:36 UTC · Revision 1
Source evidence
block: recompute nr_integrity_segments in blk_insert_cloned_request
core-osv · Original sourcePublished 24 Jul 2026, 15:23 UTC
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 , 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 account
osv:CVE-2026-64232
Kernel
Fixed versions: 6.12.92, 6.18.34, 7.0.11
Complete source record
{
"id": "2547e14d02f2c03b203006f1ceb517a20f5b1b305d205c20237d3f8dbaabf4da",
"url": "https://osv.dev/vulnerability/CVE-2026-64232",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "block: recompute nr_integrity_segments in blk_insert_cloned_request",
"summary": "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 , 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 account",
"evidence": "osv:CVE-2026-64232",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.12.92",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.34",
"evidence": "/affected/1/ranges"
},
{
"value": "7.0.11",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "critical",
"structured": {
"id": "CVE-2026-64232",
"aliases": [
"CVE-2026-64232"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "76c313f658d2752e8527610677164aa7094ef7a5"
},
{
"fixed": "53a01bcc0242590eda4c452a5bd996f62457113b"
},
{
"fixed": "0943f81e1b3176f27dbaf6db268fc69d8a94f0ba"
},
{
"fixed": "42929c98d044f126508baf54a65b0f87f932fa75"
},
{
"fixed": "2c6e6a18a37b905cb584eb0dda3ae482162a81ca"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64232.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.12.0"
},
{
"fixed": "6.12.92"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.34"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.0.11"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64232.json"
}
}
],
"modified": "2026-10-28T02:30:50.769938405Z",
"provider": "osv",
"references": [
"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",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64232.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-64232",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64232.json"
}
},
"related_cves": [
{
"value": "CVE-2026-64232",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 519482,
"published_at": "2026-07-24T15:23:13.729+00:00"
}