Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CERTFR-2026-AVI-0809
Vulnerability from certfr_avis - Published: 2026-06-26 - Updated: 2026-06-26
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et un déni de service.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
References
| Title | Publication Time | Tags | |||
|---|---|---|---|---|---|
|
|||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Debian",
"product": {
"name": "Debian",
"vendor": {
"name": "Debian",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-45842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45842"
},
{
"name": "CVE-2026-45845",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45845"
},
{
"name": "CVE-2025-22069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22069"
},
{
"name": "CVE-2026-46319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46319"
},
{
"name": "CVE-2026-31486",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31486"
},
{
"name": "CVE-2026-23346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23346"
},
{
"name": "CVE-2026-23247",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23247"
},
{
"name": "CVE-2026-46170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46170"
},
{
"name": "CVE-2026-46117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46117"
},
{
"name": "CVE-2025-71289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71289"
},
{
"name": "CVE-2026-31613",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31613"
},
{
"name": "CVE-2026-43331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43331"
},
{
"name": "CVE-2026-46158",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46158"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-46137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46137"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2026-23469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23469"
},
{
"name": "CVE-2026-31420",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31420"
},
{
"name": "CVE-2026-46203",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46203"
},
{
"name": "CVE-2026-31663",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31663"
},
{
"name": "CVE-2026-45846",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45846"
},
{
"name": "CVE-2026-46323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46323"
},
{
"name": "CVE-2025-68768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68768"
},
{
"name": "CVE-2026-46315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46315"
},
{
"name": "CVE-2025-68251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68251"
},
{
"name": "CVE-2026-46321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46321"
},
{
"name": "CVE-2026-52908",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52908"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-45844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45844"
},
{
"name": "CVE-2026-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52910"
},
{
"name": "CVE-2026-45930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45930"
},
{
"name": "CVE-2026-46274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46274"
},
{
"name": "CVE-2026-46244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46244"
},
{
"name": "CVE-2026-31717",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31717"
},
{
"name": "CVE-2026-52911",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52911"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2026-46316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46316"
},
{
"name": "CVE-2026-46160",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46160"
},
{
"name": "CVE-2026-43303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43303"
},
{
"name": "CVE-2026-43245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43245"
},
{
"name": "CVE-2026-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2026-23394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23394"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-23272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23272"
},
{
"name": "CVE-2026-31560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31560"
},
{
"name": "CVE-2026-46216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46216"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-45850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45850"
},
{
"name": "CVE-2026-43116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43116"
},
{
"name": "CVE-2026-46322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46322"
},
{
"name": "CVE-2026-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"name": "CVE-2026-43219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43219"
}
],
"initial_release_date": "2026-06-26T00:00:00",
"last_revision_date": "2026-06-26T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0809",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-06-26T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de Debian. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et un d\u00e9ni de service.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de Debian",
"vendor_advisories": [
{
"published_at": "2026-06-21",
"title": "Bulletin de s\u00e9curit\u00e9 Debian msg00266",
"url": "https://lists.debian.org/debian-security-announce/2026/msg00266.html"
}
]
}
CVE-2025-22069 (GCVE-0-2025-22069)
Vulnerability from cvelistv5 – Published: 2025-04-16 14:12 – Updated: 2026-06-01 16:05
VLAI
EPSS
Title
riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler
Summary
In the Linux kernel, the following vulnerability has been resolved:
riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler
Naresh Kamboju reported a "Bad frame pointer" kernel warning while
running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the
same issue with the following command:
```
$ cd /sys/kernel/debug/tracing
$ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events
$ echo 1 > events/fprobes/enable
$ echo 1 > tracing_on
$ sleep 1
```
And we can get the following kernel warning:
[ 127.692888] ------------[ cut here ]------------
[ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000
[ 127.693755] from func do_nanosleep return to ffffffff800ccb16
[ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be
[ 127.699894] Modules linked in:
[ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32
[ 127.701453] Hardware name: riscv-virtio,qemu (DT)
[ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be
[ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be
[ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10
[ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000
[ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80
[ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20
[ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000
[ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038
[ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0
[ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068
[ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001
[ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e
[ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18
[ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003
[ 127.703292] [<ffffffff8013b5e0>] ftrace_return_to_handler+0x1b2/0x1be
[ 127.703760] [<ffffffff80017bce>] return_to_handler+0x16/0x26
[ 127.704009] [<ffffffff80017bb8>] return_to_handler+0x0/0x26
[ 127.704057] [<ffffffff800d3352>] common_nsleep+0x42/0x54
[ 127.704117] [<ffffffff800d44a2>] __riscv_sys_clock_nanosleep+0xba/0x10a
[ 127.704176] [<ffffffff80901c56>] do_trap_ecall_u+0x188/0x218
[ 127.704295] [<ffffffff8090cc3e>] handle_exception+0x14a/0x156
[ 127.705436] ---[ end trace 0000000000000000 ]---
The reason is that the stack layout for constructing argument for the
ftrace_return_to_handler in the return_to_handler does not match the
__arch_ftrace_regs structure of riscv, leading to unexpected results.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
33d4e904e24d14ff0fbc528b657ddc7c7b636e6a , < 7ed384db061a264bd806898f7ccab9b98b591488
(git)
Affected: a3ed4157b7d89800a0008de0c9e46a438a5c3745 , < 78b39c587b8f6c69140177108f9c08a75b1c7c37 (git) Affected: a3ed4157b7d89800a0008de0c9e46a438a5c3745 , < 67a5ba8f742f247bc83e46dd2313c142b1383276 (git) Affected: 6.12.75 , < 6.12.92 (semver) |
|
| Linux | Linux |
Affected:
6.14
Unaffected: 0 , < 6.14 (semver) Unaffected: 6.12.92 , ≤ 6.12.* (semver) Unaffected: 6.14.2 , ≤ 6.14.* (semver) Unaffected: 6.15 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/riscv/kernel/mcount.S"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "7ed384db061a264bd806898f7ccab9b98b591488",
"status": "affected",
"version": "33d4e904e24d14ff0fbc528b657ddc7c7b636e6a",
"versionType": "git"
},
{
"lessThan": "78b39c587b8f6c69140177108f9c08a75b1c7c37",
"status": "affected",
"version": "a3ed4157b7d89800a0008de0c9e46a438a5c3745",
"versionType": "git"
},
{
"lessThan": "67a5ba8f742f247bc83e46dd2313c142b1383276",
"status": "affected",
"version": "a3ed4157b7d89800a0008de0c9e46a438a5c3745",
"versionType": "git"
},
{
"lessThan": "6.12.92",
"status": "affected",
"version": "6.12.75",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/riscv/kernel/mcount.S"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.14"
},
{
"lessThan": "6.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.92",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.92",
"versionStartIncluding": "6.12.75",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.2",
"versionStartIncluding": "6.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"versionStartIncluding": "6.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler\n\nNaresh Kamboju reported a \"Bad frame pointer\" kernel warning while\nrunning LTP trace ftrace_stress_test.sh in riscv. We can reproduce the\nsame issue with the following command:\n\n```\n$ cd /sys/kernel/debug/tracing\n$ echo \u0027f:myprobe do_nanosleep%return args1=$retval\u0027 \u003e dynamic_events\n$ echo 1 \u003e events/fprobes/enable\n$ echo 1 \u003e tracing_on\n$ sleep 1\n```\n\nAnd we can get the following kernel warning:\n\n[ 127.692888] ------------[ cut here ]------------\n[ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000\n[ 127.693755] from func do_nanosleep return to ffffffff800ccb16\n[ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be\n[ 127.699894] Modules linked in:\n[ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32\n[ 127.701453] Hardware name: riscv-virtio,qemu (DT)\n[ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be\n[ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be\n[ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10\n[ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000\n[ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80\n[ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20\n[ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000\n[ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038\n[ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0\n[ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068\n[ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001\n[ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e\n[ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18\n[ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003\n[ 127.703292] [\u003cffffffff8013b5e0\u003e] ftrace_return_to_handler+0x1b2/0x1be\n[ 127.703760] [\u003cffffffff80017bce\u003e] return_to_handler+0x16/0x26\n[ 127.704009] [\u003cffffffff80017bb8\u003e] return_to_handler+0x0/0x26\n[ 127.704057] [\u003cffffffff800d3352\u003e] common_nsleep+0x42/0x54\n[ 127.704117] [\u003cffffffff800d44a2\u003e] __riscv_sys_clock_nanosleep+0xba/0x10a\n[ 127.704176] [\u003cffffffff80901c56\u003e] do_trap_ecall_u+0x188/0x218\n[ 127.704295] [\u003cffffffff8090cc3e\u003e] handle_exception+0x14a/0x156\n[ 127.705436] ---[ end trace 0000000000000000 ]---\n\nThe reason is that the stack layout for constructing argument for the\nftrace_return_to_handler in the return_to_handler does not match the\n__arch_ftrace_regs structure of riscv, leading to unexpected results."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-01T16:05:09.341Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/7ed384db061a264bd806898f7ccab9b98b591488"
},
{
"url": "https://git.kernel.org/stable/c/78b39c587b8f6c69140177108f9c08a75b1c7c37"
},
{
"url": "https://git.kernel.org/stable/c/67a5ba8f742f247bc83e46dd2313c142b1383276"
}
],
"title": "riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-22069",
"datePublished": "2025-04-16T14:12:22.357Z",
"dateReserved": "2024-12-29T08:45:45.814Z",
"dateUpdated": "2026-06-01T16:05:09.341Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-68251 (GCVE-0-2025-68251)
Vulnerability from cvelistv5 – Published: 2025-12-16 14:32 – Updated: 2026-05-23 16:02
VLAI
EPSS
Title
erofs: avoid infinite loops due to corrupted subpage compact indexes
Summary
In the Linux kernel, the following vulnerability has been resolved:
erofs: avoid infinite loops due to corrupted subpage compact indexes
Robert reported an infinite loop observed by two crafted images.
The root cause is that `clusterofs` can be larger than `lclustersize`
for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:
blocksize = lclustersize = 512 lcn = 6 clusterofs = 515
Move the corresponding check for full compress indexes to
`z_erofs_load_lcluster_from_disk()` to also cover subpage compact
compress indexes.
It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`
check, since it should be placed right after
`z_erofs_load_{compact,full}_lcluster()`.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
8d2517aaeea3ab8651bb517bca8f3c8664d318ea , < dbfac1b85d0753996ddfef636934d431b588dd1f
(git)
Affected: 8d2517aaeea3ab8651bb517bca8f3c8664d318ea , < 8675447a8794983f2b7e694b378112772c17635e (git) Affected: 8d2517aaeea3ab8651bb517bca8f3c8664d318ea , < e13d315ae077bb7c3c6027cc292401bc0f4ec683 (git) Affected: 3f691aa676f29586e83e6c032713554a290418c3 (git) Affected: 22438a34d383ec2789eaf450728e38abc53051f8 (git) Affected: 6.6.16 , < 6.7 (semver) Affected: 6.7.4 , < 6.8 (semver) |
|
| Linux | Linux |
Affected:
6.8
Unaffected: 0 , < 6.8 (semver) Unaffected: 6.12.91 , ≤ 6.12.* (semver) Unaffected: 6.17.6 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/erofs/zmap.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "dbfac1b85d0753996ddfef636934d431b588dd1f",
"status": "affected",
"version": "8d2517aaeea3ab8651bb517bca8f3c8664d318ea",
"versionType": "git"
},
{
"lessThan": "8675447a8794983f2b7e694b378112772c17635e",
"status": "affected",
"version": "8d2517aaeea3ab8651bb517bca8f3c8664d318ea",
"versionType": "git"
},
{
"lessThan": "e13d315ae077bb7c3c6027cc292401bc0f4ec683",
"status": "affected",
"version": "8d2517aaeea3ab8651bb517bca8f3c8664d318ea",
"versionType": "git"
},
{
"status": "affected",
"version": "3f691aa676f29586e83e6c032713554a290418c3",
"versionType": "git"
},
{
"status": "affected",
"version": "22438a34d383ec2789eaf450728e38abc53051f8",
"versionType": "git"
},
{
"lessThan": "6.7",
"status": "affected",
"version": "6.6.16",
"versionType": "semver"
},
{
"lessThan": "6.8",
"status": "affected",
"version": "6.7.4",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/erofs/zmap.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.8"
},
{
"lessThan": "6.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.91",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.6",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.6.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.7.4",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: avoid infinite loops due to corrupted subpage compact indexes\n\nRobert reported an infinite loop observed by two crafted images.\n\nThe root cause is that `clusterofs` can be larger than `lclustersize`\nfor !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:\n\n blocksize = lclustersize = 512 lcn = 6 clusterofs = 515\n\nMove the corresponding check for full compress indexes to\n`z_erofs_load_lcluster_from_disk()` to also cover subpage compact\ncompress indexes.\n\nIt also fixes the position of `m-\u003etype \u003e= Z_EROFS_LCLUSTER_TYPE_MAX`\ncheck, since it should be placed right after\n`z_erofs_load_{compact,full}_lcluster()`."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-23T16:02:29.626Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/dbfac1b85d0753996ddfef636934d431b588dd1f"
},
{
"url": "https://git.kernel.org/stable/c/8675447a8794983f2b7e694b378112772c17635e"
},
{
"url": "https://git.kernel.org/stable/c/e13d315ae077bb7c3c6027cc292401bc0f4ec683"
}
],
"title": "erofs: avoid infinite loops due to corrupted subpage compact indexes",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-68251",
"datePublished": "2025-12-16T14:32:17.979Z",
"dateReserved": "2025-12-16T13:41:40.266Z",
"dateUpdated": "2026-05-23T16:02:29.626Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-68768 (GCVE-0-2025-68768)
Vulnerability from cvelistv5 – Published: 2026-01-13 15:28 – Updated: 2026-06-19 11:57
VLAI
EPSS
Title
inet: frags: flush pending skbs in fqdir_pre_exit()
Summary
In the Linux kernel, the following vulnerability has been resolved:
inet: frags: flush pending skbs in fqdir_pre_exit()
We have been seeing occasional deadlocks on pernet_ops_rwsem since
September in NIPA. The stuck task was usually modprobe (often loading
a driver like ipvlan), trying to take the lock as a Writer.
lockdep does not track readers for rwsems so the read wasn't obvious
from the reports.
On closer inspection the Reader holding the lock was conntrack looping
forever in nf_conntrack_cleanup_net_list(). Based on past experience
with occasional NIPA crashes I looked thru the tests which run before
the crash and noticed that the crash follows ip_defrag.sh. An immediate
red flag. Scouring thru (de)fragmentation queues reveals skbs sitting
around, holding conntrack references.
The problem is that since conntrack depends on nf_defrag_ipv6,
nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its
netns exit hooks run _after_ conntrack's netns exit hook.
Flush all fragment queue SKBs during fqdir_pre_exit() to release
conntrack references before conntrack cleanup runs. Also flush
the queues in timer expiry handlers when they discover fqdir->dead
is set, in case packet sneaks in while we're running the pre_exit
flush.
The commit under Fixes is not exactly the culprit, but I think
previously the timer firing would eventually unblock the spinning
conntrack.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db , < 22ee4010866da81aeee08e1ea3fddbe418feb212
(git)
Affected: d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db , < 543555954b1ee8d1903a7020324efb41b0c97428 (git) Affected: d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db , < c70df25214ac9b32b53e18e6ae3b8f073ffa6903 (git) Affected: d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db , < 006a5035b495dec008805df249f92c22c89c3d2e (git) |
|
| Linux | Linux |
Affected:
5.3
Unaffected: 0 , < 5.3 (semver) Unaffected: 6.6.143 , ≤ 6.6.* (semver) Unaffected: 6.12.93 , ≤ 6.12.* (semver) Unaffected: 6.18.3 , ≤ 6.18.* (semver) Unaffected: 6.19 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/inet_frag.h",
"include/net/ipv6_frag.h",
"net/ipv4/inet_fragment.c",
"net/ipv4/ip_fragment.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "22ee4010866da81aeee08e1ea3fddbe418feb212",
"status": "affected",
"version": "d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db",
"versionType": "git"
},
{
"lessThan": "543555954b1ee8d1903a7020324efb41b0c97428",
"status": "affected",
"version": "d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db",
"versionType": "git"
},
{
"lessThan": "c70df25214ac9b32b53e18e6ae3b8f073ffa6903",
"status": "affected",
"version": "d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db",
"versionType": "git"
},
{
"lessThan": "006a5035b495dec008805df249f92c22c89c3d2e",
"status": "affected",
"version": "d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/inet_frag.h",
"include/net/ipv6_frag.h",
"net/ipv4/inet_fragment.c",
"net/ipv4/ip_fragment.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.3"
},
{
"lessThan": "5.3",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.143",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.93",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.143",
"versionStartIncluding": "5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.93",
"versionStartIncluding": "5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.3",
"versionStartIncluding": "5.3",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "5.3",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: flush pending skbs in fqdir_pre_exit()\n\nWe have been seeing occasional deadlocks on pernet_ops_rwsem since\nSeptember in NIPA. The stuck task was usually modprobe (often loading\na driver like ipvlan), trying to take the lock as a Writer.\nlockdep does not track readers for rwsems so the read wasn\u0027t obvious\nfrom the reports.\n\nOn closer inspection the Reader holding the lock was conntrack looping\nforever in nf_conntrack_cleanup_net_list(). Based on past experience\nwith occasional NIPA crashes I looked thru the tests which run before\nthe crash and noticed that the crash follows ip_defrag.sh. An immediate\nred flag. Scouring thru (de)fragmentation queues reveals skbs sitting\naround, holding conntrack references.\n\nThe problem is that since conntrack depends on nf_defrag_ipv6,\nnf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its\nnetns exit hooks run _after_ conntrack\u0027s netns exit hook.\n\nFlush all fragment queue SKBs during fqdir_pre_exit() to release\nconntrack references before conntrack cleanup runs. Also flush\nthe queues in timer expiry handlers when they discover fqdir-\u003edead\nis set, in case packet sneaks in while we\u0027re running the pre_exit\nflush.\n\nThe commit under Fixes is not exactly the culprit, but I think\npreviously the timer firing would eventually unblock the spinning\nconntrack."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-19T11:57:29.047Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/22ee4010866da81aeee08e1ea3fddbe418feb212"
},
{
"url": "https://git.kernel.org/stable/c/543555954b1ee8d1903a7020324efb41b0c97428"
},
{
"url": "https://git.kernel.org/stable/c/c70df25214ac9b32b53e18e6ae3b8f073ffa6903"
},
{
"url": "https://git.kernel.org/stable/c/006a5035b495dec008805df249f92c22c89c3d2e"
}
],
"title": "inet: frags: flush pending skbs in fqdir_pre_exit()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-68768",
"datePublished": "2026-01-13T15:28:47.106Z",
"dateReserved": "2025-12-24T10:30:51.034Z",
"dateUpdated": "2026-06-19T11:57:29.047Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-71289 (GCVE-0-2025-71289)
Vulnerability from cvelistv5 – Published: 2026-05-06 11:32 – Updated: 2026-06-01 16:05
VLAI
EPSS
Title
fs/ntfs3: handle attr_set_size() errors when truncating files
Summary
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: handle attr_set_size() errors when truncating files
If attr_set_size() fails while truncating down, the error is silently
ignored and the inode may be left in an inconsistent state.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
4342306f0f0d5ff4315a204d315c1b51b914fca5 , < 3a718675d6af4992e34ffe86b8f36d471a5afe0e
(git)
Affected: 4342306f0f0d5ff4315a204d315c1b51b914fca5 , < d73dcd1520d65a34420761641a36b951b14c8c53 (git) Affected: 4342306f0f0d5ff4315a204d315c1b51b914fca5 , < 6dfea43d11513b7f2892529de55e8f0855108a2c (git) Affected: 4342306f0f0d5ff4315a204d315c1b51b914fca5 , < 576248a34b927e93b2fd3fff7df735ba73ad7d01 (git) |
|
| Linux | Linux |
Affected:
5.15
Unaffected: 0 , < 5.15 (semver) Unaffected: 6.12.92 , ≤ 6.12.* (semver) Unaffected: 6.18.34 , ≤ 6.18.* (semver) Unaffected: 6.19.6 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/ntfs3/file.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3a718675d6af4992e34ffe86b8f36d471a5afe0e",
"status": "affected",
"version": "4342306f0f0d5ff4315a204d315c1b51b914fca5",
"versionType": "git"
},
{
"lessThan": "d73dcd1520d65a34420761641a36b951b14c8c53",
"status": "affected",
"version": "4342306f0f0d5ff4315a204d315c1b51b914fca5",
"versionType": "git"
},
{
"lessThan": "6dfea43d11513b7f2892529de55e8f0855108a2c",
"status": "affected",
"version": "4342306f0f0d5ff4315a204d315c1b51b914fca5",
"versionType": "git"
},
{
"lessThan": "576248a34b927e93b2fd3fff7df735ba73ad7d01",
"status": "affected",
"version": "4342306f0f0d5ff4315a204d315c1b51b914fca5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/ntfs3/file.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.15"
},
{
"lessThan": "5.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.92",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.34",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.92",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.34",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.6",
"versionStartIncluding": "5.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "5.15",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: handle attr_set_size() errors when truncating files\n\nIf attr_set_size() fails while truncating down, the error is silently\nignored and the inode may be left in an inconsistent state."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-01T16:05:50.615Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3a718675d6af4992e34ffe86b8f36d471a5afe0e"
},
{
"url": "https://git.kernel.org/stable/c/d73dcd1520d65a34420761641a36b951b14c8c53"
},
{
"url": "https://git.kernel.org/stable/c/6dfea43d11513b7f2892529de55e8f0855108a2c"
},
{
"url": "https://git.kernel.org/stable/c/576248a34b927e93b2fd3fff7df735ba73ad7d01"
}
],
"title": "fs/ntfs3: handle attr_set_size() errors when truncating files",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-71289",
"datePublished": "2026-05-06T11:32:21.715Z",
"dateReserved": "2026-05-06T11:31:45.509Z",
"dateUpdated": "2026-06-01T16:05:50.615Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-23247 (GCVE-0-2026-23247)
Vulnerability from cvelistv5 – Published: 2026-03-18 10:05 – Updated: 2026-06-19 11:57
VLAI
EPSS
Title
tcp: secure_seq: add back ports to TS offset
Summary
In the Linux kernel, the following vulnerability has been resolved:
tcp: secure_seq: add back ports to TS offset
This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")
tcp_tw_recycle went away in 2017.
Zhouyan Deng reported off-path TCP source port leakage via
SYN cookie side-channel that can be fixed in multiple ways.
One of them is to bring back TCP ports in TS offset randomization.
As a bonus, we perform a single siphash() computation
to provide both an ISN and a TS offset.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
28ee1b746f493b7c62347d714f58fbf4f70df4f0 , < 5da5662181ef8a251e3ba564903002c2e87de452
(git)
Affected: 28ee1b746f493b7c62347d714f58fbf4f70df4f0 , < eae2f14ab2efccdb7480fae7d42c4b0116ef8805 (git) Affected: 28ee1b746f493b7c62347d714f58fbf4f70df4f0 , < 46e5b0d7cf55821527adea471ffe52a5afbd9caf (git) Affected: 28ee1b746f493b7c62347d714f58fbf4f70df4f0 , < 165573e41f2f66ef98940cf65f838b2cb575d9d1 (git) Affected: 443fac9f2618b93cbc5ab068dc594530236b3a23 (git) Affected: 4.10.14 , < 4.11 (semver) |
|
| Linux | Linux |
Affected:
4.11
Unaffected: 0 , < 4.11 (semver) Unaffected: 6.12.94 , ≤ 6.12.* (semver) Unaffected: 6.18.17 , ≤ 6.18.* (semver) Unaffected: 6.19.7 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/secure_seq.h",
"include/net/tcp.h",
"net/core/secure_seq.c",
"net/ipv4/syncookies.c",
"net/ipv4/tcp_input.c",
"net/ipv4/tcp_ipv4.c",
"net/ipv6/syncookies.c",
"net/ipv6/tcp_ipv6.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5da5662181ef8a251e3ba564903002c2e87de452",
"status": "affected",
"version": "28ee1b746f493b7c62347d714f58fbf4f70df4f0",
"versionType": "git"
},
{
"lessThan": "eae2f14ab2efccdb7480fae7d42c4b0116ef8805",
"status": "affected",
"version": "28ee1b746f493b7c62347d714f58fbf4f70df4f0",
"versionType": "git"
},
{
"lessThan": "46e5b0d7cf55821527adea471ffe52a5afbd9caf",
"status": "affected",
"version": "28ee1b746f493b7c62347d714f58fbf4f70df4f0",
"versionType": "git"
},
{
"lessThan": "165573e41f2f66ef98940cf65f838b2cb575d9d1",
"status": "affected",
"version": "28ee1b746f493b7c62347d714f58fbf4f70df4f0",
"versionType": "git"
},
{
"status": "affected",
"version": "443fac9f2618b93cbc5ab068dc594530236b3a23",
"versionType": "git"
},
{
"lessThan": "4.11",
"status": "affected",
"version": "4.10.14",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/secure_seq.h",
"include/net/tcp.h",
"net/core/secure_seq.c",
"net/ipv4/syncookies.c",
"net/ipv4/tcp_input.c",
"net/ipv4/tcp_ipv4.c",
"net/ipv6/syncookies.c",
"net/ipv6/tcp_ipv6.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.11"
},
{
"lessThan": "4.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.94",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.17",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.94",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.17",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.7",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "4.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.10.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: secure_seq: add back ports to TS offset\n\nThis reverts 28ee1b746f49 (\"secure_seq: downgrade to per-host timestamp offsets\")\n\ntcp_tw_recycle went away in 2017.\n\nZhouyan Deng reported off-path TCP source port leakage via\nSYN cookie side-channel that can be fixed in multiple ways.\n\nOne of them is to bring back TCP ports in TS offset randomization.\n\nAs a bonus, we perform a single siphash() computation\nto provide both an ISN and a TS offset."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-19T11:57:32.014Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5da5662181ef8a251e3ba564903002c2e87de452"
},
{
"url": "https://git.kernel.org/stable/c/eae2f14ab2efccdb7480fae7d42c4b0116ef8805"
},
{
"url": "https://git.kernel.org/stable/c/46e5b0d7cf55821527adea471ffe52a5afbd9caf"
},
{
"url": "https://git.kernel.org/stable/c/165573e41f2f66ef98940cf65f838b2cb575d9d1"
}
],
"title": "tcp: secure_seq: add back ports to TS offset",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23247",
"datePublished": "2026-03-18T10:05:09.353Z",
"dateReserved": "2026-01-13T15:37:45.989Z",
"dateUpdated": "2026-06-19T11:57:32.014Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-23272 (GCVE-0-2026-23272)
Vulnerability from cvelistv5 – Published: 2026-03-20 08:08 – Updated: 2026-05-23 16:04
VLAI
EPSS
Title
netfilter: nf_tables: unconditionally bump set->nelems before insertion
Summary
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: unconditionally bump set->nelems before insertion
In case that the set is full, a new element gets published then removed
without waiting for the RCU grace period, while RCU reader can be
walking over it already.
To address this issue, add the element transaction even if set is full,
but toggle the set_full flag to report -ENFILE so the abort path safely
unwinds the set to its previous state.
As for element updates, decrement set->nelems to restore it.
A simpler fix is to call synchronize_rcu() in the error path.
However, with a large batch adding elements to already maxed-out set,
this could cause noticeable slowdown of such batches.
Severity
7.8 (High)
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
35d0ac9070ef619e3bf44324375878a1c540387b , < e3ccb11fc8249759d23326038c8db987ddaabc77
(git)
Affected: 35d0ac9070ef619e3bf44324375878a1c540387b , < 86bc4b1a0f672d47ac19f9022432cb6a2e01cb33 (git) Affected: 35d0ac9070ef619e3bf44324375878a1c540387b , < 6826131c7674329335ca25df2550163eb8a1fd0c (git) Affected: 35d0ac9070ef619e3bf44324375878a1c540387b , < ccb8c8f3c1127cf34d18c737309897c68046bf21 (git) Affected: 35d0ac9070ef619e3bf44324375878a1c540387b , < def602e498a4f951da95c95b1b8ce8ae68aa733a (git) Affected: fefdd79403e89b0c673965343b92e2e01e2713a8 (git) Affected: 4.9.33 , < 4.10 (semver) |
|
| Linux | Linux |
Affected:
4.10
Unaffected: 0 , < 4.10 (semver) Unaffected: 6.6.141 , ≤ 6.6.* (semver) Unaffected: 6.12.91 , ≤ 6.12.* (semver) Unaffected: 6.18.17 , ≤ 6.18.* (semver) Unaffected: 6.19.7 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/netfilter/nf_tables_api.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "e3ccb11fc8249759d23326038c8db987ddaabc77",
"status": "affected",
"version": "35d0ac9070ef619e3bf44324375878a1c540387b",
"versionType": "git"
},
{
"lessThan": "86bc4b1a0f672d47ac19f9022432cb6a2e01cb33",
"status": "affected",
"version": "35d0ac9070ef619e3bf44324375878a1c540387b",
"versionType": "git"
},
{
"lessThan": "6826131c7674329335ca25df2550163eb8a1fd0c",
"status": "affected",
"version": "35d0ac9070ef619e3bf44324375878a1c540387b",
"versionType": "git"
},
{
"lessThan": "ccb8c8f3c1127cf34d18c737309897c68046bf21",
"status": "affected",
"version": "35d0ac9070ef619e3bf44324375878a1c540387b",
"versionType": "git"
},
{
"lessThan": "def602e498a4f951da95c95b1b8ce8ae68aa733a",
"status": "affected",
"version": "35d0ac9070ef619e3bf44324375878a1c540387b",
"versionType": "git"
},
{
"status": "affected",
"version": "fefdd79403e89b0c673965343b92e2e01e2713a8",
"versionType": "git"
},
{
"lessThan": "4.10",
"status": "affected",
"version": "4.9.33",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/netfilter/nf_tables_api.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.10"
},
{
"lessThan": "4.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.141",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.91",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.17",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.141",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.91",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.17",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.7",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.9.33",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: unconditionally bump set-\u003enelems before insertion\n\nIn case that the set is full, a new element gets published then removed\nwithout waiting for the RCU grace period, while RCU reader can be\nwalking over it already.\n\nTo address this issue, add the element transaction even if set is full,\nbut toggle the set_full flag to report -ENFILE so the abort path safely\nunwinds the set to its previous state.\n\nAs for element updates, decrement set-\u003enelems to restore it.\n\nA simpler fix is to call synchronize_rcu() in the error path.\nHowever, with a large batch adding elements to already maxed-out set,\nthis could cause noticeable slowdown of such batches."
}
],
"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"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-23T16:04:26.049Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/e3ccb11fc8249759d23326038c8db987ddaabc77"
},
{
"url": "https://git.kernel.org/stable/c/86bc4b1a0f672d47ac19f9022432cb6a2e01cb33"
},
{
"url": "https://git.kernel.org/stable/c/6826131c7674329335ca25df2550163eb8a1fd0c"
},
{
"url": "https://git.kernel.org/stable/c/ccb8c8f3c1127cf34d18c737309897c68046bf21"
},
{
"url": "https://git.kernel.org/stable/c/def602e498a4f951da95c95b1b8ce8ae68aa733a"
}
],
"title": "netfilter: nf_tables: unconditionally bump set-\u003enelems before insertion",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23272",
"datePublished": "2026-03-20T08:08:52.946Z",
"dateReserved": "2026-01-13T15:37:45.991Z",
"dateUpdated": "2026-05-23T16:04:26.049Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-23346 (GCVE-0-2026-23346)
Vulnerability from cvelistv5 – Published: 2026-03-25 10:27 – Updated: 2026-06-19 11:57
VLAI
EPSS
Title
arm64: io: Extract user memory type in ioremap_prot()
Summary
In the Linux kernel, the following vulnerability has been resolved:
arm64: io: Extract user memory type in ioremap_prot()
The only caller of ioremap_prot() outside of the generic ioremap()
implementation is generic_access_phys(), which passes a 'pgprot_t' value
determined from the user mapping of the target 'pfn' being accessed by
the kernel. On arm64, the 'pgprot_t' contains all of the non-address
bits from the pte, including the permission controls, and so we end up
returning a new user mapping from ioremap_prot() which faults when
accessed from the kernel on systems with PAN:
| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000
| ...
| Call trace:
| __memcpy_fromio+0x80/0xf8
| generic_access_phys+0x20c/0x2b8
| __access_remote_vm+0x46c/0x5b8
| access_remote_vm+0x18/0x30
| environ_read+0x238/0x3e8
| vfs_read+0xe4/0x2b0
| ksys_read+0xcc/0x178
| __arm64_sys_read+0x4c/0x68
Extract only the memory type from the user 'pgprot_t' in ioremap_prot()
and assert that we're being passed a user mapping, to protect us against
any changes in future that may require additional handling. To avoid
falsely flagging users of ioremap(), provide our own ioremap() macro
which simply wraps __ioremap_prot().
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
893dea9ccd08dab924839354aba21d4ed7a9abc0 , < 64858b76ec67c5fc40fef8ec1841fecb78c1ebde
(git)
Affected: 893dea9ccd08dab924839354aba21d4ed7a9abc0 , < eeecafce5afffb4da703666ebefbd4d6e2a5abf6 (git) Affected: 893dea9ccd08dab924839354aba21d4ed7a9abc0 , < 3d64dcc0799c2d6921ba027716b7be721eb19fa8 (git) Affected: 893dea9ccd08dab924839354aba21d4ed7a9abc0 , < d1ad8fe7f72d73e1617bac79f2ec7a3bedf47e2a (git) Affected: 893dea9ccd08dab924839354aba21d4ed7a9abc0 , < 8f098037139b294050053123ab2bc0f819d08932 (git) |
|
| Linux | Linux |
Affected:
6.0
Unaffected: 0 , < 6.0 (semver) Unaffected: 6.6.143 , ≤ 6.6.* (semver) Unaffected: 6.12.93 , ≤ 6.12.* (semver) Unaffected: 6.18.17 , ≤ 6.18.* (semver) Unaffected: 6.19.7 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm64/include/asm/io.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "64858b76ec67c5fc40fef8ec1841fecb78c1ebde",
"status": "affected",
"version": "893dea9ccd08dab924839354aba21d4ed7a9abc0",
"versionType": "git"
},
{
"lessThan": "eeecafce5afffb4da703666ebefbd4d6e2a5abf6",
"status": "affected",
"version": "893dea9ccd08dab924839354aba21d4ed7a9abc0",
"versionType": "git"
},
{
"lessThan": "3d64dcc0799c2d6921ba027716b7be721eb19fa8",
"status": "affected",
"version": "893dea9ccd08dab924839354aba21d4ed7a9abc0",
"versionType": "git"
},
{
"lessThan": "d1ad8fe7f72d73e1617bac79f2ec7a3bedf47e2a",
"status": "affected",
"version": "893dea9ccd08dab924839354aba21d4ed7a9abc0",
"versionType": "git"
},
{
"lessThan": "8f098037139b294050053123ab2bc0f819d08932",
"status": "affected",
"version": "893dea9ccd08dab924839354aba21d4ed7a9abc0",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm64/include/asm/io.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.0"
},
{
"lessThan": "6.0",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.143",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.93",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.17",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.143",
"versionStartIncluding": "6.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.93",
"versionStartIncluding": "6.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.17",
"versionStartIncluding": "6.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.7",
"versionStartIncluding": "6.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "6.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: io: Extract user memory type in ioremap_prot()\n\nThe only caller of ioremap_prot() outside of the generic ioremap()\nimplementation is generic_access_phys(), which passes a \u0027pgprot_t\u0027 value\ndetermined from the user mapping of the target \u0027pfn\u0027 being accessed by\nthe kernel. On arm64, the \u0027pgprot_t\u0027 contains all of the non-address\nbits from the pte, including the permission controls, and so we end up\nreturning a new user mapping from ioremap_prot() which faults when\naccessed from the kernel on systems with PAN:\n\n | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000\n | ...\n | Call trace:\n | __memcpy_fromio+0x80/0xf8\n | generic_access_phys+0x20c/0x2b8\n | __access_remote_vm+0x46c/0x5b8\n | access_remote_vm+0x18/0x30\n | environ_read+0x238/0x3e8\n | vfs_read+0xe4/0x2b0\n | ksys_read+0xcc/0x178\n | __arm64_sys_read+0x4c/0x68\n\nExtract only the memory type from the user \u0027pgprot_t\u0027 in ioremap_prot()\nand assert that we\u0027re being passed a user mapping, to protect us against\nany changes in future that may require additional handling. To avoid\nfalsely flagging users of ioremap(), provide our own ioremap() macro\nwhich simply wraps __ioremap_prot()."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-19T11:57:35.219Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/64858b76ec67c5fc40fef8ec1841fecb78c1ebde"
},
{
"url": "https://git.kernel.org/stable/c/eeecafce5afffb4da703666ebefbd4d6e2a5abf6"
},
{
"url": "https://git.kernel.org/stable/c/3d64dcc0799c2d6921ba027716b7be721eb19fa8"
},
{
"url": "https://git.kernel.org/stable/c/d1ad8fe7f72d73e1617bac79f2ec7a3bedf47e2a"
},
{
"url": "https://git.kernel.org/stable/c/8f098037139b294050053123ab2bc0f819d08932"
}
],
"title": "arm64: io: Extract user memory type in ioremap_prot()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23346",
"datePublished": "2026-03-25T10:27:33.133Z",
"dateReserved": "2026-01-13T15:37:45.999Z",
"dateUpdated": "2026-06-19T11:57:35.219Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-23394 (GCVE-0-2026-23394)
Vulnerability from cvelistv5 – Published: 2026-03-25 10:33 – Updated: 2026-06-01 16:11
VLAI
EPSS
Title
af_unix: Give up GC if MSG_PEEK intervened.
Summary
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Give up GC if MSG_PEEK intervened.
Igor Ushakov reported that GC purged the receive queue of
an alive socket due to a race with MSG_PEEK with a nice repro.
This is the exact same issue previously fixed by commit
cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK").
After GC was replaced with the current algorithm, the cited
commit removed the locking dance in unix_peek_fds() and
reintroduced the same issue.
The problem is that MSG_PEEK bumps a file refcount without
interacting with GC.
Consider an SCC containing sk-A and sk-B, where sk-A is
close()d but can be recv()ed via sk-B.
The bad thing happens if sk-A is recv()ed with MSG_PEEK from
sk-B and sk-B is close()d while GC is checking unix_vertex_dead()
for sk-A and sk-B.
GC thread User thread
--------- -----------
unix_vertex_dead(sk-A)
-> true <------.
\
`------ recv(sk-B, MSG_PEEK)
invalidate !! -> sk-A's file refcount : 1 -> 2
close(sk-B)
-> sk-B's file refcount : 2 -> 1
unix_vertex_dead(sk-B)
-> true
Initially, sk-A's file refcount is 1 by the inflight fd in sk-B
recvq. GC thinks sk-A is dead because the file refcount is the
same as the number of its inflight fds.
However, sk-A's file refcount is bumped silently by MSG_PEEK,
which invalidates the previous evaluation.
At this moment, sk-B's file refcount is 2; one by the open fd,
and one by the inflight fd in sk-A. The subsequent close()
releases one refcount by the former.
Finally, GC incorrectly concludes that both sk-A and sk-B are dead.
One option is to restore the locking dance in unix_peek_fds(),
but we can resolve this more elegantly thanks to the new algorithm.
The point is that the issue does not occur without the subsequent
close() and we actually do not need to synchronise MSG_PEEK with
the dead SCC detection.
When the issue occurs, close() and GC touch the same file refcount.
If GC sees the refcount being decremented by close(), it can just
give up garbage-collecting the SCC.
Therefore, we only need to signal the race during MSG_PEEK with
a proper memory barrier to make it visible to the GC.
Let's use seqcount_t to notify GC when MSG_PEEK occurs and let
it defer the SCC to the next run.
This way no locking is needed on the MSG_PEEK side, and we can
avoid imposing a penalty on every MSG_PEEK unnecessarily.
Note that we can retry within unix_scc_dead() if MSG_PEEK is
detected, but we do not do so to avoid hung task splat from
abusive MSG_PEEK calls.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
7b1ffbd3b22e755d481d49647dcb7c5cfbde5844 , < 3106f326f67c03dd9da4ca64663d11e40138cf40
(git)
Affected: 118f457da9ed58a79e24b73c2ef0aa1987241f0e , < e3dd56fb5683ba80bf8d7a2f9aa21cfa53f05202 (git) Affected: 118f457da9ed58a79e24b73c2ef0aa1987241f0e , < 72cf49ad50c16270b52bc512d9c2df5743922968 (git) Affected: 118f457da9ed58a79e24b73c2ef0aa1987241f0e , < 37dd7ab332396eb8dd80b2dc7ea4b61abf767436 (git) Affected: 118f457da9ed58a79e24b73c2ef0aa1987241f0e , < e5b31d988a41549037b8d8721a3c3cae893d8670 (git) Affected: 61a75360dca93c945ef6bd757f8b8a96f39b77cb (git) Affected: 6.6.93 , < 6.6.142 (semver) Affected: 6.1.141 , < 6.2 (semver) |
|
| Linux | Linux |
Affected:
6.10
Unaffected: 0 , < 6.10 (semver) Unaffected: 6.6.142 , ≤ 6.6.* (semver) Unaffected: 6.12.92 , ≤ 6.12.* (semver) Unaffected: 6.18.23 , ≤ 6.18.* (semver) Unaffected: 6.19.10 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/unix/af_unix.c",
"net/unix/af_unix.h",
"net/unix/garbage.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3106f326f67c03dd9da4ca64663d11e40138cf40",
"status": "affected",
"version": "7b1ffbd3b22e755d481d49647dcb7c5cfbde5844",
"versionType": "git"
},
{
"lessThan": "e3dd56fb5683ba80bf8d7a2f9aa21cfa53f05202",
"status": "affected",
"version": "118f457da9ed58a79e24b73c2ef0aa1987241f0e",
"versionType": "git"
},
{
"lessThan": "72cf49ad50c16270b52bc512d9c2df5743922968",
"status": "affected",
"version": "118f457da9ed58a79e24b73c2ef0aa1987241f0e",
"versionType": "git"
},
{
"lessThan": "37dd7ab332396eb8dd80b2dc7ea4b61abf767436",
"status": "affected",
"version": "118f457da9ed58a79e24b73c2ef0aa1987241f0e",
"versionType": "git"
},
{
"lessThan": "e5b31d988a41549037b8d8721a3c3cae893d8670",
"status": "affected",
"version": "118f457da9ed58a79e24b73c2ef0aa1987241f0e",
"versionType": "git"
},
{
"status": "affected",
"version": "61a75360dca93c945ef6bd757f8b8a96f39b77cb",
"versionType": "git"
},
{
"lessThan": "6.6.142",
"status": "affected",
"version": "6.6.93",
"versionType": "semver"
},
{
"lessThan": "6.2",
"status": "affected",
"version": "6.1.141",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/unix/af_unix.c",
"net/unix/af_unix.h",
"net/unix/garbage.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.6.*",
"status": "unaffected",
"version": "6.6.142",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.92",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.142",
"versionStartIncluding": "6.6.93",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.92",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.23",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.1.141",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Give up GC if MSG_PEEK intervened.\n\nIgor Ushakov reported that GC purged the receive queue of\nan alive socket due to a race with MSG_PEEK with a nice repro.\n\nThis is the exact same issue previously fixed by commit\ncbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\").\n\nAfter GC was replaced with the current algorithm, the cited\ncommit removed the locking dance in unix_peek_fds() and\nreintroduced the same issue.\n\nThe problem is that MSG_PEEK bumps a file refcount without\ninteracting with GC.\n\nConsider an SCC containing sk-A and sk-B, where sk-A is\nclose()d but can be recv()ed via sk-B.\n\nThe bad thing happens if sk-A is recv()ed with MSG_PEEK from\nsk-B and sk-B is close()d while GC is checking unix_vertex_dead()\nfor sk-A and sk-B.\n\n GC thread User thread\n --------- -----------\n unix_vertex_dead(sk-A)\n -\u003e true \u003c------.\n \\\n `------ recv(sk-B, MSG_PEEK)\n invalidate !! -\u003e sk-A\u0027s file refcount : 1 -\u003e 2\n\n close(sk-B)\n -\u003e sk-B\u0027s file refcount : 2 -\u003e 1\n unix_vertex_dead(sk-B)\n -\u003e true\n\nInitially, sk-A\u0027s file refcount is 1 by the inflight fd in sk-B\nrecvq. GC thinks sk-A is dead because the file refcount is the\nsame as the number of its inflight fds.\n\nHowever, sk-A\u0027s file refcount is bumped silently by MSG_PEEK,\nwhich invalidates the previous evaluation.\n\nAt this moment, sk-B\u0027s file refcount is 2; one by the open fd,\nand one by the inflight fd in sk-A. The subsequent close()\nreleases one refcount by the former.\n\nFinally, GC incorrectly concludes that both sk-A and sk-B are dead.\n\nOne option is to restore the locking dance in unix_peek_fds(),\nbut we can resolve this more elegantly thanks to the new algorithm.\n\nThe point is that the issue does not occur without the subsequent\nclose() and we actually do not need to synchronise MSG_PEEK with\nthe dead SCC detection.\n\nWhen the issue occurs, close() and GC touch the same file refcount.\nIf GC sees the refcount being decremented by close(), it can just\ngive up garbage-collecting the SCC.\n\nTherefore, we only need to signal the race during MSG_PEEK with\na proper memory barrier to make it visible to the GC.\n\nLet\u0027s use seqcount_t to notify GC when MSG_PEEK occurs and let\nit defer the SCC to the next run.\n\nThis way no locking is needed on the MSG_PEEK side, and we can\navoid imposing a penalty on every MSG_PEEK unnecessarily.\n\nNote that we can retry within unix_scc_dead() if MSG_PEEK is\ndetected, but we do not do so to avoid hung task splat from\nabusive MSG_PEEK calls."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-01T16:11:07.633Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3106f326f67c03dd9da4ca64663d11e40138cf40"
},
{
"url": "https://git.kernel.org/stable/c/e3dd56fb5683ba80bf8d7a2f9aa21cfa53f05202"
},
{
"url": "https://git.kernel.org/stable/c/72cf49ad50c16270b52bc512d9c2df5743922968"
},
{
"url": "https://git.kernel.org/stable/c/37dd7ab332396eb8dd80b2dc7ea4b61abf767436"
},
{
"url": "https://git.kernel.org/stable/c/e5b31d988a41549037b8d8721a3c3cae893d8670"
}
],
"title": "af_unix: Give up GC if MSG_PEEK intervened.",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23394",
"datePublished": "2026-03-25T10:33:18.180Z",
"dateReserved": "2026-01-13T15:37:46.011Z",
"dateUpdated": "2026-06-01T16:11:07.633Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-23469 (GCVE-0-2026-23469)
Vulnerability from cvelistv5 – Published: 2026-04-03 15:15 – Updated: 2026-06-01 16:11
VLAI
EPSS
Title
drm/imagination: Synchronize interrupts before suspending the GPU
Summary
In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: Synchronize interrupts before suspending the GPU
The runtime PM suspend callback doesn't know whether the IRQ handler is
in progress on a different CPU core and doesn't wait for it to finish.
Depending on timing, the IRQ handler could be running while the GPU is
suspended, leading to kernel crashes when trying to access GPU
registers. See example signature below.
In a power off sequence initiated by the runtime PM suspend callback,
wait for any IRQ handlers in progress on other CPU cores to finish, by
calling synchronize_irq().
At the same time, remove the runtime PM resume/put calls in the threaded
IRQ handler. On top of not being the right approach to begin with, and
being at the wrong place as they should have wrapped all GPU register
accesses, the driver would hit a deadlock between synchronize_irq()
being called from a runtime PM suspend callback, holding the device
power lock, and the resume callback requiring the same.
Example crash signature on a TI AM68 SK platform:
[ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError
[ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT
[ 337.241246] Tainted: [M]=MACHINE_CHECK
[ 337.241249] Hardware name: Texas Instruments AM68 SK (DT)
[ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 337.241256] pc : pvr_riscv_irq_pending+0xc/0x24
[ 337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310
[ 337.241282] sp : ffff800085b0bd30
[ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10
[ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000
[ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30
[ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001
[ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40
[ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a
[ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00
[ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003
[ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000
[ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000
[ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT
[ 337.241342] Tainted: [M]=MACHINE_CHECK
[ 337.241343] Hardware name: Texas Instruments AM68 SK (DT)
[ 337.241345] Call trace:
[ 337.241348] show_stack+0x18/0x24 (C)
[ 337.241357] dump_stack_lvl+0x60/0x80
[ 337.241364] dump_stack+0x18/0x24
[ 337.241368] vpanic+0x124/0x2ec
[ 337.241373] abort+0x0/0x4
[ 337.241377] add_taint+0x0/0xbc
[ 337.241384] arm64_serror_panic+0x70/0x80
[ 337.241389] do_serror+0x3c/0x74
[ 337.241392] el1h_64_error_handler+0x30/0x48
[ 337.241400] el1h_64_error+0x6c/0x70
[ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P)
[ 337.241410] irq_thread_fn+0x2c/0xb0
[ 337.241416] irq_thread+0x170/0x334
[ 337.241421] kthread+0x12c/0x210
[ 337.241428] ret_from_fork+0x10/0x20
[ 337.241434] SMP: stopping secondary CPUs
[ 337.241451] Kernel Offset: disabled
[ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b
[ 337.241456] Memory Limit: none
[ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
cc1aeedb98ad347c06ff59e991b2f94dfb4c565d , < 50257450196e4bba11c562117847ea409660a7de
(git)
Affected: cc1aeedb98ad347c06ff59e991b2f94dfb4c565d , < 772f3653eef50ea7cf721b05d8e275f93bc460f3 (git) Affected: cc1aeedb98ad347c06ff59e991b2f94dfb4c565d , < 8e0c15e426a056b9fb604cf87a1dfdec4d61e407 (git) Affected: cc1aeedb98ad347c06ff59e991b2f94dfb4c565d , < 2d7f05cddf4c268cc36256a2476946041dbdd36d (git) |
|
| Linux | Linux |
Affected:
6.8
Unaffected: 0 , < 6.8 (semver) Unaffected: 6.12.92 , ≤ 6.12.* (semver) Unaffected: 6.18.20 , ≤ 6.18.* (semver) Unaffected: 6.19.10 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/imagination/pvr_device.c",
"drivers/gpu/drm/imagination/pvr_power.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "50257450196e4bba11c562117847ea409660a7de",
"status": "affected",
"version": "cc1aeedb98ad347c06ff59e991b2f94dfb4c565d",
"versionType": "git"
},
{
"lessThan": "772f3653eef50ea7cf721b05d8e275f93bc460f3",
"status": "affected",
"version": "cc1aeedb98ad347c06ff59e991b2f94dfb4c565d",
"versionType": "git"
},
{
"lessThan": "8e0c15e426a056b9fb604cf87a1dfdec4d61e407",
"status": "affected",
"version": "cc1aeedb98ad347c06ff59e991b2f94dfb4c565d",
"versionType": "git"
},
{
"lessThan": "2d7f05cddf4c268cc36256a2476946041dbdd36d",
"status": "affected",
"version": "cc1aeedb98ad347c06ff59e991b2f94dfb4c565d",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/gpu/drm/imagination/pvr_device.c",
"drivers/gpu/drm/imagination/pvr_power.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.8"
},
{
"lessThan": "6.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.92",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.20",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.92",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.20",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.10",
"versionStartIncluding": "6.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: Synchronize interrupts before suspending the GPU\n\nThe runtime PM suspend callback doesn\u0027t know whether the IRQ handler is\nin progress on a different CPU core and doesn\u0027t wait for it to finish.\n\nDepending on timing, the IRQ handler could be running while the GPU is\nsuspended, leading to kernel crashes when trying to access GPU\nregisters. See example signature below.\n\nIn a power off sequence initiated by the runtime PM suspend callback,\nwait for any IRQ handlers in progress on other CPU cores to finish, by\ncalling synchronize_irq().\n\nAt the same time, remove the runtime PM resume/put calls in the threaded\nIRQ handler. On top of not being the right approach to begin with, and\nbeing at the wrong place as they should have wrapped all GPU register\naccesses, the driver would hit a deadlock between synchronize_irq()\nbeing called from a runtime PM suspend callback, holding the device\npower lock, and the resume callback requiring the same.\n\nExample crash signature on a TI AM68 SK platform:\n\n [ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError\n [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT\n [ 337.241246] Tainted: [M]=MACHINE_CHECK\n [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT)\n [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n [ 337.241256] pc : pvr_riscv_irq_pending+0xc/0x24\n [ 337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310\n [ 337.241282] sp : ffff800085b0bd30\n [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10\n [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000\n [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30\n [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001\n [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40\n [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a\n [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00\n [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003\n [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000\n [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000\n [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt\n [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT\n [ 337.241342] Tainted: [M]=MACHINE_CHECK\n [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT)\n [ 337.241345] Call trace:\n [ 337.241348] show_stack+0x18/0x24 (C)\n [ 337.241357] dump_stack_lvl+0x60/0x80\n [ 337.241364] dump_stack+0x18/0x24\n [ 337.241368] vpanic+0x124/0x2ec\n [ 337.241373] abort+0x0/0x4\n [ 337.241377] add_taint+0x0/0xbc\n [ 337.241384] arm64_serror_panic+0x70/0x80\n [ 337.241389] do_serror+0x3c/0x74\n [ 337.241392] el1h_64_error_handler+0x30/0x48\n [ 337.241400] el1h_64_error+0x6c/0x70\n [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P)\n [ 337.241410] irq_thread_fn+0x2c/0xb0\n [ 337.241416] irq_thread+0x170/0x334\n [ 337.241421] kthread+0x12c/0x210\n [ 337.241428] ret_from_fork+0x10/0x20\n [ 337.241434] SMP: stopping secondary CPUs\n [ 337.241451] Kernel Offset: disabled\n [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b\n [ 337.241456] Memory Limit: none\n [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---"
}
],
"providerMetadata": {
"dateUpdated": "2026-06-01T16:11:19.052Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/50257450196e4bba11c562117847ea409660a7de"
},
{
"url": "https://git.kernel.org/stable/c/772f3653eef50ea7cf721b05d8e275f93bc460f3"
},
{
"url": "https://git.kernel.org/stable/c/8e0c15e426a056b9fb604cf87a1dfdec4d61e407"
},
{
"url": "https://git.kernel.org/stable/c/2d7f05cddf4c268cc36256a2476946041dbdd36d"
}
],
"title": "drm/imagination: Synchronize interrupts before suspending the GPU",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23469",
"datePublished": "2026-04-03T15:15:48.599Z",
"dateReserved": "2026-01-13T15:37:46.021Z",
"dateUpdated": "2026-06-01T16:11:19.052Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-31420 (GCVE-0-2026-31420)
Vulnerability from cvelistv5 – Published: 2026-04-13 13:40 – Updated: 2026-06-01 16:11
VLAI
EPSS
Title
bridge: mrp: reject zero test interval to avoid OOM panic
Summary
In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Linux | Linux |
Affected:
20f6a05ef63594feb0c6dfbd629da0448b43124d , < 630a15a31c2034b5b697f4aabc769b9d80d82446
(git)
Affected: 20f6a05ef63594feb0c6dfbd629da0448b43124d , < e8ec80430bfa520e7352155d6ac632e527cba7aa (git) Affected: 20f6a05ef63594feb0c6dfbd629da0448b43124d , < c9bc352f716d1bebfe43354bce539ec2d0223b30 (git) Affected: 20f6a05ef63594feb0c6dfbd629da0448b43124d , < fa6e24963342de4370e3a3c9af41e38277b74cf3 (git) |
|
| Linux | Linux |
Affected:
5.8
Unaffected: 0 , < 5.8 (semver) Unaffected: 6.12.92 , ≤ 6.12.* (semver) Unaffected: 6.18.34 , ≤ 6.18.* (semver) Unaffected: 6.19.12 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix) |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/bridge/br_mrp_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "630a15a31c2034b5b697f4aabc769b9d80d82446",
"status": "affected",
"version": "20f6a05ef63594feb0c6dfbd629da0448b43124d",
"versionType": "git"
},
{
"lessThan": "e8ec80430bfa520e7352155d6ac632e527cba7aa",
"status": "affected",
"version": "20f6a05ef63594feb0c6dfbd629da0448b43124d",
"versionType": "git"
},
{
"lessThan": "c9bc352f716d1bebfe43354bce539ec2d0223b30",
"status": "affected",
"version": "20f6a05ef63594feb0c6dfbd629da0448b43124d",
"versionType": "git"
},
{
"lessThan": "fa6e24963342de4370e3a3c9af41e38277b74cf3",
"status": "affected",
"version": "20f6a05ef63594feb0c6dfbd629da0448b43124d",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/bridge/br_mrp_netlink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.8"
},
{
"lessThan": "5.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.92",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.34",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.92",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.34",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.12",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"versionStartIncluding": "5.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: mrp: reject zero test interval to avoid OOM panic\n\nbr_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied\ninterval value from netlink without validation. When interval is 0,\nusecs_to_jiffies(0) yields 0, causing the delayed work\n(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule\nitself with zero delay. This creates a tight loop on system_percpu_wq\nthat allocates and transmits MRP test frames at maximum rate, exhausting\nall system memory and causing a kernel panic via OOM deadlock.\n\nThe same zero-interval issue applies to br_mrp_start_in_test_parse()\nfor interconnect test frames.\n\nUse NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both\nIFLA_BRIDGE_MRP_START_TEST_INTERVAL and\nIFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the\nnetlink attribute parsing layer before the value ever reaches the\nworkqueue scheduling code. This is consistent with how other bridge\nsubsystems (br_fdb, br_mst) enforce range constraints on netlink\nattributes."
}
],
"providerMetadata": {
"dateUpdated": "2026-06-01T16:11:26.083Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/630a15a31c2034b5b697f4aabc769b9d80d82446"
},
{
"url": "https://git.kernel.org/stable/c/e8ec80430bfa520e7352155d6ac632e527cba7aa"
},
{
"url": "https://git.kernel.org/stable/c/c9bc352f716d1bebfe43354bce539ec2d0223b30"
},
{
"url": "https://git.kernel.org/stable/c/fa6e24963342de4370e3a3c9af41e38277b74cf3"
}
],
"title": "bridge: mrp: reject zero test interval to avoid OOM panic",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-31420",
"datePublished": "2026-04-13T13:40:24.594Z",
"dateReserved": "2026-03-09T15:48:24.088Z",
"dateUpdated": "2026-06-01T16:11:26.083Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
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.
Loading…
Loading…