CVE-2026-98974 (GCVE-0-2026-98974)
Vulnerability from cvelistv5 – Published: 2026-10-23 12:19 – Updated: 2026-10-24 14:09
VLAI
EPSS
VEX
Title
xfs: fix exchange-range-to-eof file size exchange
Summary
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix exchange-range-to-eof file size exchange
Norbert Szetei posted a patch containing an incomplete description of a
bug in XFS_IOC_EXCHANGE_RANGE's TO_EOF flag. The bug tricks
exchange-range into modifying a file so that it has shared blocks
starting beyond EOF, which is never allowed because files never have
written data beyond EOF, and you can only share written data blocks.
This is key to all the incorrect behavior that follows.
Eventually I got from Norbert a description of what's going wrong:
> Fair. Here it is with physical block numbers, 4k blocks. peer is the file
> that gets rewritten and file1 is the one that ends up with the flag
> cleared.
>
> Start, nothing shared:
>
> peer size 4096 -> [100]
> file1 size 12288 -> [200] [201] [202]
> donor1 size 4096 -> [300]
> donor2 size 4096 -> [400]
>
> 1. FICLONERANGE peer's block into file1's middle slot:
>
> peer size 4096 -> [100]
> file1 size 12288 -> [200] [100] [202] reflink flag set
> ^^^^^ both files own block 100
>
> 2. XFS_IOC_EXCHANGE_RANGE file1 against donor1, file1_offset 0,
> file2_offset 8192, length 0, TO_EOF. One block is exchanged, and the sizes
> are exchanged with it:
>
> file1 size 4096 -> [200] [100] [300] reflink flag set
> ^^^^^^^^^^^ still owned, now past the size
> donor1 size 12288 -> [202]
>
> file1 says it is one block long while it still owns three. Nothing was
> unmapped. file2_offset is block 2, so this exchange cannot clear a flag.
>
> 3. XFS_IOC_EXCHANGE_RANGE file1 against donor2, both offsets 0, length 4096.
> By i_disk_size this is two one-block files exchanging everything, so
> xmi_can_exchange_reflink_flags() agrees and the flag is cleared:
>
> file1 size 4096 -> [400] [100] [300] reflink flag CLEARED
> donor2 size 4096 -> [200]
>
> Block 100 is still shared with peer.
>
> 4. pwrite(file1, 4096, 4096), which is file1's second slot, block 100.
> xfs_is_cow_inode(file1) is false, so no CoW:
>
> peer size 4096 -> [100] same block, new contents
>
> Block 100 is the only one that matters here. PoC below, it reads a file
> called peer in the current directory. The filesystem needs reflink and
> exchange-range, which mkfs.xfs 7.x turns on by default.
So yes, TO_EOF is screwing up the file size even if it's actually
exchanging the data block correctly. The following is the intended
behavior of XFS_EXCHANGE_RANGE_TO_EOF, as described by its manpage:
"Ignore the length parameter. All bytes in file1_fd from file1_offset
to EOF are moved to file2_fd, and file2's size is set to
(file2_offset+(file1_length-file1_offset)). Meanwhile, all bytes in
file2 from file2_offset to EOF are moved to file1 and file1's size is
set to (file1_offset+(file2_length-file2_offset))."
In other words, if we only exchange a portion of the file data, then we
should only exchange the portion of the file size that relates to the
exchanged data. Unfortunately, the code swaps the ondisk file size and
the incore file sizes, which is incorrect if the caller passes in a
nonzero offset.
Having confused the file sizes, the PoC uses a second exchange-range
call on what looks like a non-reflinked single-block file. Because the
file size is set incorrectly, exchange-range thinks it's exchanging the
full contents of two files and clears the reflink flag on the broken
file. That enables an extending write of the broken file to rewrite the
shared block that's just past EOF. This has become known colloquially
as refluxfs.
Once the file sizes are set correctly, the second exchange-range no
longer thinks that it's doing a full-contents swap, so it won't clear
the reflink flag on either of its file arguments.
Norbert followed up to an earlier version of this patch with a second
complaint about us not handling the i_disk_size state correctly:
> The offsets are bounded against the incore i_size but subtracted from
>
---truncated---
Severity
7.8 (High)
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
966ceafc7a437105ecfe1cadb3747b2965a260ca , < b361d32b884f8ddcb9bad5d99b69eece648f8e43
(git)
Affected: 966ceafc7a437105ecfe1cadb3747b2965a260ca , < cf32eb20dfacfd2e92ce86ba1fece9ae5f98a7d8 (git) Affected: 966ceafc7a437105ecfe1cadb3747b2965a260ca , < 952b5c99a840c2bff1f6645fd5e06e1db6ec2623 (git) Affected: 966ceafc7a437105ecfe1cadb3747b2965a260ca , < 7dfb218c829c1acb626e0fe92c5fddb9a26a03e9 (git) |
guessed | |
| Linux | Linux |
Affected:
6.10
Unaffected: 0 , < 6.10 (semver) Unaffected: 6.12.114 , ≤ 6.12.* (semver) Unaffected: 6.18.57 , ≤ 6.18.* (semver) Unaffected: 7.2.11 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/xfs/libxfs/xfs_exchmaps.c",
"fs/xfs/xfs_exchrange.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b361d32b884f8ddcb9bad5d99b69eece648f8e43",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
},
{
"lessThan": "cf32eb20dfacfd2e92ce86ba1fece9ae5f98a7d8",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
},
{
"lessThan": "952b5c99a840c2bff1f6645fd5e06e1db6ec2623",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
},
{
"lessThan": "7dfb218c829c1acb626e0fe92c5fddb9a26a03e9",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/xfs/libxfs/xfs_exchmaps.c",
"fs/xfs/xfs_exchrange.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.10"
},
{
"lessThan": "6.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.114",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.57",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.114",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.57",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2.11",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.3",
"versionStartIncluding": "6.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix exchange-range-to-eof file size exchange\n\nNorbert Szetei posted a patch containing an incomplete description of a\nbug in XFS_IOC_EXCHANGE_RANGE\u0027s TO_EOF flag. The bug tricks\nexchange-range into modifying a file so that it has shared blocks\nstarting beyond EOF, which is never allowed because files never have\nwritten data beyond EOF, and you can only share written data blocks.\nThis is key to all the incorrect behavior that follows.\n\nEventually I got from Norbert a description of what\u0027s going wrong:\n\n\u003e Fair. Here it is with physical block numbers, 4k blocks. peer is the file\n\u003e that gets rewritten and file1 is the one that ends up with the flag\n\u003e cleared.\n\u003e\n\u003e Start, nothing shared:\n\u003e\n\u003e\tpeer size 4096 -\u003e [100]\n\u003e\tfile1 size 12288 -\u003e [200] [201] [202]\n\u003e\tdonor1 size 4096 -\u003e [300]\n\u003e\tdonor2 size 4096 -\u003e [400]\n\u003e\n\u003e 1. FICLONERANGE peer\u0027s block into file1\u0027s middle slot:\n\u003e\n\u003e\tpeer size 4096 -\u003e [100]\n\u003e\tfile1 size 12288 -\u003e [200] [100] [202] reflink flag set\n\u003e ^^^^^ both files own block 100\n\u003e\n\u003e 2. XFS_IOC_EXCHANGE_RANGE file1 against donor1, file1_offset 0,\n\u003e file2_offset 8192, length 0, TO_EOF. One block is exchanged, and the sizes\n\u003e are exchanged with it:\n\u003e\n\u003e\tfile1 size 4096 -\u003e [200] [100] [300] reflink flag set\n\u003e ^^^^^^^^^^^ still owned, now past the size\n\u003e\tdonor1 size 12288 -\u003e [202]\n\u003e\n\u003e file1 says it is one block long while it still owns three. Nothing was\n\u003e unmapped. file2_offset is block 2, so this exchange cannot clear a flag.\n\u003e\n\u003e 3. XFS_IOC_EXCHANGE_RANGE file1 against donor2, both offsets 0, length 4096.\n\u003e By i_disk_size this is two one-block files exchanging everything, so\n\u003e xmi_can_exchange_reflink_flags() agrees and the flag is cleared:\n\u003e\n\u003e\tfile1 size 4096 -\u003e [400] [100] [300] reflink flag CLEARED\n\u003e\tdonor2 size 4096 -\u003e [200]\n\u003e\n\u003e Block 100 is still shared with peer.\n\u003e\n\u003e 4. pwrite(file1, 4096, 4096), which is file1\u0027s second slot, block 100.\n\u003e xfs_is_cow_inode(file1) is false, so no CoW:\n\u003e\n\u003e\tpeer size 4096 -\u003e [100] same block, new contents\n\u003e\n\u003e Block 100 is the only one that matters here. PoC below, it reads a file\n\u003e called peer in the current directory. The filesystem needs reflink and\n\u003e exchange-range, which mkfs.xfs 7.x turns on by default.\n\nSo yes, TO_EOF is screwing up the file size even if it\u0027s actually\nexchanging the data block correctly. The following is the intended\nbehavior of XFS_EXCHANGE_RANGE_TO_EOF, as described by its manpage:\n\n\"Ignore the length parameter. All bytes in file1_fd from file1_offset\n to EOF are moved to file2_fd, and file2\u0027s size is set to\n (file2_offset+(file1_length-file1_offset)). Meanwhile, all bytes in\n file2 from file2_offset to EOF are moved to file1 and file1\u0027s size is\n set to (file1_offset+(file2_length-file2_offset)).\"\n\nIn other words, if we only exchange a portion of the file data, then we\nshould only exchange the portion of the file size that relates to the\nexchanged data. Unfortunately, the code swaps the ondisk file size and\nthe incore file sizes, which is incorrect if the caller passes in a\nnonzero offset.\n\nHaving confused the file sizes, the PoC uses a second exchange-range\ncall on what looks like a non-reflinked single-block file. Because the\nfile size is set incorrectly, exchange-range thinks it\u0027s exchanging the\nfull contents of two files and clears the reflink flag on the broken\nfile. That enables an extending write of the broken file to rewrite the\nshared block that\u0027s just past EOF. This has become known colloquially\nas refluxfs.\n\nOnce the file sizes are set correctly, the second exchange-range no\nlonger thinks that it\u0027s doing a full-contents swap, so it won\u0027t clear\nthe reflink flag on either of its file arguments.\n\nNorbert followed up to an earlier version of this patch with a second\ncomplaint about us not handling the i_disk_size state correctly:\n\n\u003e The offsets are bounded against the incore i_size but subtracted from\n\u003e\n---truncated---"
}
],
"metrics": [
{
"cvssV3_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",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The attacker-controlled offsets and XFS_EXCHANGE_RANGE_TO_EOF flag enter through ioctl(2), then xfs_file_ioctl -\u003e xfs_ioc_exchange_range -\u003e xfs_exchange_range -\u003e xfs_exchrange_mappings/xfs_exchmaps_init_intent, the two patched functions; no network data reaches this path.\nAC:L - On XFS with reflink and exchange-range enabled, one process can deterministically clone a readable peer block, issue the TO_EOF and full-range exchanges, then pwrite; every transition is attacker-controlled and no race is required.\nPR:L - xfs_exchange_range requires read/write access to the exchanged files, which can be attacker-owned. The protected peer is only the FICLONERANGE source, and vfs_clone_file_range requires MAY_READ on it without any capability check.\nUI:N - The attacker alone invokes FICLONERANGE, two XFS_IOC_EXCHANGE_RANGE operations, and pwrite against an already-mounted XFS filesystem; no victim must open a file or mount attacker-supplied media.\nS:U - The incorrect size exchange in xfs_exchmaps_init_intent and resulting CoW bypass affect files and privileges within the same host kernel security authority; no VM, IOMMU, or other scope boundary is crossed.\nC:H - After xfs_exchmaps_clear_reflink removes XFS_DIFLAG2_REFLINK, xfs_is_cow_inode returns false and pwrite can alter a still-shared block in a readable root-owned setuid executable; its unchanged privileged metadata permits root execution and access to all host data.\nI:H - The non-CoW pwrite supplies controlled full-block contents to a physical extent still owned by a root-owned readable file, allowing arbitrary modification of protected files on the same XFS volume despite DAC.\nA:H - The same controlled shared-block overwrite can corrupt the headers or code of essential readable system binaries, libraries, or boot files on XFS, causing complete service or system failure."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-24T14:09:44.115Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b361d32b884f8ddcb9bad5d99b69eece648f8e43"
},
{
"url": "https://git.kernel.org/stable/c/cf32eb20dfacfd2e92ce86ba1fece9ae5f98a7d8"
},
{
"url": "https://git.kernel.org/stable/c/952b5c99a840c2bff1f6645fd5e06e1db6ec2623"
},
{
"url": "https://git.kernel.org/stable/c/7dfb218c829c1acb626e0fe92c5fddb9a26a03e9"
}
],
"title": "xfs: fix exchange-range-to-eof file size exchange",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-98974",
"datePublished": "2026-10-23T12:19:47.424Z",
"dateReserved": "2026-09-25T10:25:14.383Z",
"dateUpdated": "2026-10-24T14:09:44.115Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-98974",
"date": "2026-10-24",
"epss": "0.00209",
"percentile": "0.10527"
},
"microsoft_vex": {
"current_release_date": "2026-10-24T01:10:32.000Z",
"cve": "CVE-2026-98974",
"id": "msrc_CVE-2026-98974",
"initial_release_date": "2026-10-24T01:10:32.000Z",
"product_status:under_investigation": "1",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "xfs: fix exchange-range-to-eof file size exchange",
"url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-98974.json",
"version": "1"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/xfs/libxfs/xfs_exchmaps.c",
"fs/xfs/xfs_exchrange.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b361d32b884f8ddcb9bad5d99b69eece648f8e43",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
},
{
"lessThan": "cf32eb20dfacfd2e92ce86ba1fece9ae5f98a7d8",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
},
{
"lessThan": "952b5c99a840c2bff1f6645fd5e06e1db6ec2623",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
},
{
"lessThan": "7dfb218c829c1acb626e0fe92c5fddb9a26a03e9",
"status": "affected",
"version": "966ceafc7a437105ecfe1cadb3747b2965a260ca",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/xfs/libxfs/xfs_exchmaps.c",
"fs/xfs/xfs_exchrange.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.10"
},
{
"lessThan": "6.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.114",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.57",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix exchange-range-to-eof file size exchange\n\nNorbert Szetei posted a patch containing an incomplete description of a\nbug in XFS_IOC_EXCHANGE_RANGE\u0027s TO_EOF flag. The bug tricks\nexchange-range into modifying a file so that it has shared blocks\nstarting beyond EOF, which is never allowed because files never have\nwritten data beyond EOF, and you can only share written data blocks.\nThis is key to all the incorrect behavior that follows.\n\nEventually I got from Norbert a description of what\u0027s going wrong:\n\n\u003e Fair. Here it is with physical block numbers, 4k blocks. peer is the file\n\u003e that gets rewritten and file1 is the one that ends up with the flag\n\u003e cleared.\n\u003e\n\u003e Start, nothing shared:\n\u003e\n\u003e\tpeer size 4096 -\u003e [100]\n\u003e\tfile1 size 12288 -\u003e [200] [201] [202]\n\u003e\tdonor1 size 4096 -\u003e [300]\n\u003e\tdonor2 size 4096 -\u003e [400]\n\u003e\n\u003e 1. FICLONERANGE peer\u0027s block into file1\u0027s middle slot:\n\u003e\n\u003e\tpeer size 4096 -\u003e [100]\n\u003e\tfile1 size 12288 -\u003e [200] [100] [202] reflink flag set\n\u003e ^^^^^ both files own block 100\n\u003e\n\u003e 2. XFS_IOC_EXCHANGE_RANGE file1 against donor1, file1_offset 0,\n\u003e file2_offset 8192, length 0, TO_EOF. One block is exchanged, and the sizes\n\u003e are exchanged with it:\n\u003e\n\u003e\tfile1 size 4096 -\u003e [200] [100] [300] reflink flag set\n\u003e ^^^^^^^^^^^ still owned, now past the size\n\u003e\tdonor1 size 12288 -\u003e [202]\n\u003e\n\u003e file1 says it is one block long while it still owns three. Nothing was\n\u003e unmapped. file2_offset is block 2, so this exchange cannot clear a flag.\n\u003e\n\u003e 3. XFS_IOC_EXCHANGE_RANGE file1 against donor2, both offsets 0, length 4096.\n\u003e By i_disk_size this is two one-block files exchanging everything, so\n\u003e xmi_can_exchange_reflink_flags() agrees and the flag is cleared:\n\u003e\n\u003e\tfile1 size 4096 -\u003e [400] [100] [300] reflink flag CLEARED\n\u003e\tdonor2 size 4096 -\u003e [200]\n\u003e\n\u003e Block 100 is still shared with peer.\n\u003e\n\u003e 4. pwrite(file1, 4096, 4096), which is file1\u0027s second slot, block 100.\n\u003e xfs_is_cow_inode(file1) is false, so no CoW:\n\u003e\n\u003e\tpeer size 4096 -\u003e [100] same block, new contents\n\u003e\n\u003e Block 100 is the only one that matters here. PoC below, it reads a file\n\u003e called peer in the current directory. The filesystem needs reflink and\n\u003e exchange-range, which mkfs.xfs 7.x turns on by default.\n\nSo yes, TO_EOF is screwing up the file size even if it\u0027s actually\nexchanging the data block correctly. The following is the intended\nbehavior of XFS_EXCHANGE_RANGE_TO_EOF, as described by its manpage:\n\n\"Ignore the length parameter. All bytes in file1_fd from file1_offset\n to EOF are moved to file2_fd, and file2\u0027s size is set to\n (file2_offset+(file1_length-file1_offset)). Meanwhile, all bytes in\n file2 from file2_offset to EOF are moved to file1 and file1\u0027s size is\n set to (file1_offset+(file2_length-file2_offset)).\"\n\nIn other words, if we only exchange a portion of the file data, then we\nshould only exchange the portion of the file size that relates to the\nexchanged data. Unfortunately, the code swaps the ondisk file size and\nthe incore file sizes, which is incorrect if the caller passes in a\nnonzero offset.\n\nHaving confused the file sizes, the PoC uses a second exchange-range\ncall on what looks like a non-reflinked single-block file. Because the\nfile size is set incorrectly, exchange-range thinks it\u0027s exchanging the\nfull contents of two files and clears the reflink flag on the broken\nfile. That enables an extending write of the broken file to rewrite the\nshared block that\u0027s just past EOF. This has become known colloquially\nas refluxfs.\n\nOnce the file sizes are set correctly, the second exchange-range no\nlonger thinks that it\u0027s doing a full-contents swap, so it won\u0027t clear\nthe reflink flag on either of its file arguments.\n\nNorbert followed up to an earlier version of this patch with a second\ncomplaint about us not handling the i_disk_size state correctly:\n\n\u003e The offsets are bounded against the incore i_size but subtracted from\n\u003e\n---truncated---"
}
],
"id": "CVE-2026-98974",
"lastModified": "2026-10-24T14:16:49.923",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-10-23T13:17:19.013",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7dfb218c829c1acb626e0fe92c5fddb9a26a03e9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/952b5c99a840c2bff1f6645fd5e06e1db6ec2623"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b361d32b884f8ddcb9bad5d99b69eece648f8e43"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cf32eb20dfacfd2e92ce86ba1fece9ae5f98a7d8"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.