<Vulnerability name="CVE-2026-64232">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Low</ThreatSeverity>
    <PublicDate>2026-07-24T00:00:00</PublicDate>
    <Bugzilla id="2506791" url="https://bugzilla.redhat.com/show_bug.cgi?id=2506791" xml:lang="en:us">
kernel: block: recompute nr_integrity_segments in blk_insert_cloned_request
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>5.5</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</CVSS3ScoringVector>
    </CVSS3>
    <Details xml:lang="en:us" source="Mitre">
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-&gt;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 &gt; rq-&gt;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
&lt;linux/blk-integrity.h&gt;, 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.
    </Details>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:10">
        <ProductName>Red Hat Enterprise Linux 10</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:6">
        <ProductName>Red Hat Enterprise Linux 6</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:7">
        <ProductName>Red Hat Enterprise Linux 7</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:8">
        <ProductName>Red Hat Enterprise Linux 8</ProductName>
        <FixState>Not affected</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel</PackageName>
    </PackageState>
    <PackageState cpe="cpe:/o:redhat:enterprise_linux:9">
        <ProductName>Red Hat Enterprise Linux 9</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>kernel-rt</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-64232
https://nvd.nist.gov/vuln/detail/CVE-2026-64232
https://lore.kernel.org/linux-cve-announce/2026072419-CVE-2026-64232-51ea@gregkh/T
    </References>
</Vulnerability>