Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-37785 (GCVE-0-2025-37785)
Vulnerability from cvelistv5 – Published: 2025-04-18 07:01 – Updated: 2026-10-15 01:06| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < 14da7dbecb430e35b5889da8dae7bef33173b351
(git)
Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < e47f472a664d70a3d104a6c2a035cdff55a719b4 (git) Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < b7531a4f99c3887439d778afaf418d1a01a5f01b (git) Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < 89503e5eae64637d0fa2218912b54660effe7d93 (git) Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < 52a5509ab19a5d3afe301165d9b5787bba34d842 (git) Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < b47584c556444cf7acb66b26a62cbc348eb92b78 (git) Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < ac28c5684c1cdab650a7e5065b19e91577d37a4b (git) Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < 53bc45da8d8da92ec07877f5922b130562eb4b00 (git) Affected: ac27a0ec112a089f1a5102bc8dffc79c8c815571 , < d5e206778e96e8667d3bde695ad372c296dc9353 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.19
Unaffected: 0 , < 2.6.19 (semver) Unaffected: 5.4.293 , ≤ 5.4.* (semver) Unaffected: 5.10.236 , ≤ 5.10.* (semver) Unaffected: 5.15.180 , ≤ 5.15.* (semver) Unaffected: 6.1.134 , ≤ 6.1.* (semver) Unaffected: 6.6.87 , ≤ 6.6.* (semver) Unaffected: 6.12.23 , ≤ 6.12.* (semver) Unaffected: 6.13.11 , ≤ 6.13.* (semver) Unaffected: 6.14.2 , ≤ 6.14.* (semver) Unaffected: 6.15 , ≤ * (original_commit_for_fix) |
guessed | |
| Siemens | SIMATIC S7-1500 CPU 1518-4 PN/DP MFP |
Affected:
V3.1.6 , < *
(custom)
|
guessed | |
| Siemens | SIMATIC S7-1500 CPU 1518-4 PN/DP MFP |
Affected:
V3.1.7 , < *
(custom)
|
guessed | |
| Siemens | SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP |
Affected:
V3.1.6 , < *
(custom)
|
guessed | |
| Siemens | SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP |
Affected:
V3.1.7 , < *
(custom)
|
guessed | |
| Siemens | SIPLUS S7-1500 CPU 1518-4 PN/DP MFP |
Affected:
V3.1.6 , < *
(custom)
|
guessed | |
| Siemens | SIPLUS S7-1500 CPU 1518-4 PN/DP MFP |
Affected:
V3.1.7 , < *
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:55:07.824Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T01:06:09.448Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
}
],
"x_adpType": "supplier"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/ext4/dir.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "14da7dbecb430e35b5889da8dae7bef33173b351",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "e47f472a664d70a3d104a6c2a035cdff55a719b4",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "b7531a4f99c3887439d778afaf418d1a01a5f01b",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "89503e5eae64637d0fa2218912b54660effe7d93",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "52a5509ab19a5d3afe301165d9b5787bba34d842",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "b47584c556444cf7acb66b26a62cbc348eb92b78",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "ac28c5684c1cdab650a7e5065b19e91577d37a4b",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "53bc45da8d8da92ec07877f5922b130562eb4b00",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "d5e206778e96e8667d3bde695ad372c296dc9353",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/ext4/dir.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.19"
},
{
"lessThan": "2.6.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.293",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.236",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.180",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.134",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.87",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.11",
"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": "5.4.293",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.236",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.180",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.134",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.87",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.23",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.11",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.2",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"versionStartIncluding": "2.6.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0027.\u0027 dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0027.\u0027\nand \u0027..\u0027 as directory entries in the first data block. It first loads\nthe \u0027.\u0027 dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0027..\u0027 dir\nentry (in ext4_next_entry). It assumes the \u0027..\u0027 dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0027.\u0027 is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \"struct ext4_dir_entry_2 *de\" point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0027.\u0027 dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u003cTASK\u003e\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e"
}
],
"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 - Triggering requires a crafted ext4 image to be mounted locally and then an `unlinkat(AT_REMOVEDIR)`/rename syscall against the corrupted directory; there is no network-facing path to `ext4_empty_dir()`. Local attack vector scores higher than physical and correctly models USB/auto-mount and loop-mount delivery.\nAC:L - The condition is fully deterministic and entirely attacker-authored \u2014 setting the `.` entry\u0027s `rec_len` to exactly the block size in the image reliably slips past every sanity check in `__ext4_check_dir_entry()` and lands `de` past the block on every attempt. No race, timing, or uncontrolled memory-layout requirement.\nPR:L - Once the image is mounted (via udisks2/GNOME auto-mount of removable media on desktops and kiosks, or an fstab `user` entry), any unprivileged local user with ordinary access to the mount can invoke `rmdir` and reach `ext4_empty_dir()`; no capability check gates the path.\nUI:N - In the auto-mount scenario the attacker performs both steps themselves \u2014 inserting the media triggers the mount automatically and the same attacker issues the `rmdir` \u2014 so no action by a separate user is required.\nS:U - The out-of-bounds access, the disclosure, and the panic all occur within the kernel\u0027s own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The read reaches into the adjacent slab object/page and its contents are exfiltrated to userspace-visible dmesg through `ext4_error_inode()`, which prints the out-of-bounds `inode` and `rec_len` fields verbatim. The operation is cheaply repeatable and the neighbouring slot can be heap-groomed, making it a practical kernel heap/pointer disclosure primitive rather than a bounded one-shot leak.\nI:H - Data read out of bounds directly controls subsequent logic \u2014 if the adjacent heap bytes decode as a valid `..` entry, `ext4_empty_dir()` wrongly reports the directory empty and `rmdir`/`rename` proceeds to unlink a non-empty directory, and the OOB `rec_len` drives the following offset walk. KASAN classifies the access as a use-after-free on the neighbouring freed object, so attacker-groomed heap state translates into corrupted filesystem-metadata operations.\nA:H - The error path is reached with the attacker-controlled superblock, and `s_errors = EXT4_ERRORS_PANIC` (`fs/ext4/super.c:4364`) makes `ext4_error_inode()` call `panic()` at `super.c:735`, giving a guaranteed kernel panic. Independently, the read past the block can fault on an unmapped or poisoned page, and on debug/KASAN kernels it is an immediate BUG."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:57:31.764Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351"
},
{
"url": "https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4"
},
{
"url": "https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b"
},
{
"url": "https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93"
},
{
"url": "https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842"
},
{
"url": "https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78"
},
{
"url": "https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b"
},
{
"url": "https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00"
},
{
"url": "https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353"
}
],
"title": "ext4: fix OOB read when checking dotdot dir",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-37785",
"datePublished": "2025-04-18T07:01:27.393Z",
"dateReserved": "2025-04-16T04:51:23.940Z",
"dateUpdated": "2026-10-15T01:06:09.448Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-37785",
"date": "2026-11-02",
"epss": "0.00314",
"percentile": "0.24391"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/ext4/dir.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "14da7dbecb430e35b5889da8dae7bef33173b351",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "e47f472a664d70a3d104a6c2a035cdff55a719b4",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "b7531a4f99c3887439d778afaf418d1a01a5f01b",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "89503e5eae64637d0fa2218912b54660effe7d93",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "52a5509ab19a5d3afe301165d9b5787bba34d842",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "b47584c556444cf7acb66b26a62cbc348eb92b78",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "ac28c5684c1cdab650a7e5065b19e91577d37a4b",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "53bc45da8d8da92ec07877f5922b130562eb4b00",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "d5e206778e96e8667d3bde695ad372c296dc9353",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/ext4/dir.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.19"
},
{
"lessThan": "2.6.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.293",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.236",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.180",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.134",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.87",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5093EDFD-21CC-4898-9E34-0C31FADEF44A",
"versionEndExcluding": "5.10.236",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D19801C8-3D18-405D-9989-E6C9B30255FA",
"versionEndExcluding": "5.15.180",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "3985DEC3-0437-4177-BC42-314AB575285A",
"versionEndExcluding": "6.1.134",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "EFF24260-49B1-4251-9477-C564CFDAD25B",
"versionEndExcluding": "6.6.87",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "26CAB76D-F00F-43CE-BEAD-7097F8FB1D6C",
"versionEndExcluding": "6.12.23",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E7E864B0-8C00-4679-BA55-659B4C9C3AD3",
"versionEndExcluding": "6.13.11",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "FADAE5D8-4808-442C-B218-77B2CE8780A0",
"versionEndExcluding": "6.14.2",
"versionStartIncluding": "6.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0027.\u0027 dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0027.\u0027\nand \u0027..\u0027 as directory entries in the first data block. It first loads\nthe \u0027.\u0027 dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0027..\u0027 dir\nentry (in ext4_next_entry). It assumes the \u0027..\u0027 dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0027.\u0027 is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \"struct ext4_dir_entry_2 *de\" point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0027.\u0027 dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u003cTASK\u003e\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: correcci\u00f3n de lectura OOB al comprobar el directorio dotdot Montar un sistema de archivos da\u00f1ado con un directorio que contiene una entrada de directorio \u0027.\u0027 con rec_len == tama\u00f1o de bloque da como resultado una lectura fuera de los l\u00edmites (m\u00e1s adelante, cuando se elimina el directorio da\u00f1ado). ext4_empty_dir() asume que cada directorio ext4 contiene al menos \u0027.\u0027 y \u0027..\u0027 como entradas de directorio en el primer bloque de datos. Primero carga la entrada de directorio \u0027.\u0027, realiza comprobaciones de cordura llamando a ext4_check_dir_entry() y luego usa su miembro rec_len para calcular la ubicaci\u00f3n de la entrada de directorio \u0027..\u0027 (en ext4_next_entry). Asume que la entrada de directorio \u0027..\u0027 encaja en el mismo bloque de datos. Si el rec_len de \u0027.\u0027 Si es exactamente un bloque (4 KB), no cumple con las comprobaciones de seguridad (se considera la \u00faltima entrada de directorio del bloque de datos) y deja el puntero \"struct ext4_dir_entry_2 *de\" justo despu\u00e9s de la ranura de memoria asignada al bloque de datos. La siguiente llamada a ext4_check_dir_entry() con el nuevo valor de de desreferencia este puntero, lo que resulta en un acceso a la memoria fuera de los l\u00edmites. Para solucionar esto, extienda __ext4_check_dir_entry() para verificar las entradas de directorio \".\" que llegan al final del bloque de datos. Aseg\u00farese de ignorar las entradas de directorio falsas para la suma de comprobaci\u00f3n (verificando name_len para ver si es distinto de cero). Nota: KASAN informa que esto es un use-after-free en caso de que otra estructura se haya liberado recientemente de la ranura m\u00e1s all\u00e1 del l\u00edmite, pero en realidad es una lectura fuera de banda (OOB). Este problema fue detectado por la herramienta syzkaller. Rastreo de llamadas: [38.594108] ERROR: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e"
}
],
"id": "CVE-2025-37785",
"lastModified": "2026-10-15T02:17:48.740",
"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"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-04-18T07:15:42.693",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-10-29T07:13:23+00:00",
"cve": "CVE-2025-37785",
"id": "CVE-2025-37785",
"initial_release_date": "2025-04-18T00:00:00+00:00",
"product_status:fixed": "612",
"product_status:known_affected": "90",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: ext4: fix OOB read when checking dotdot dir",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-37785.json",
"version": "3"
}
}
}
CERTFR-2026-AVI-0880
Vulnerability from certfr_avis - Published: 2026-07-15 - Updated: 2026-07-15
De multiples vulnérabilités ont été découvertes dans les produits Siemens. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Siemens | SIMATIC | SIMATIC S7-PLCSIM Advanced toutes versions pour la vulnérabilité CVE-2026-54429 | ||
| Siemens | N/A | Desigo CC versions antérieures à 9.0.1 | ||
| Siemens | SIMATIC | SIMATIC S7-1500 versions supérieures ou égales à3.1.6 pour les vulnérabilités CVE-2021-41617, CVE-2023-28531, CVE-2023-51384, CVE-2023-52927, CVE-2024-26783, CVE-2024-27056, CVE-2024-28956, CVE-2024-36903, CVE-2024-36927, CVE-2024-42079, CVE-2024-46786, CVE-2024-47736, CVE-2024-47809, CVE-2024-49968, CVE-2024-49994, CVE-2024-49998, CVE-2024-50014, CVE-2024-50063, CVE-2024-50164, CVE-2024-50298, CVE-2024-53124, CVE-2024-53170, CVE-2024-54458, CVE-2024-56631, CVE-2024-56703, CVE-2024-56719, CVE-2024-57917, CVE-2024-57924, CVE-2024-57973, CVE-2024-57977, CVE-2024-57979, CVE-2024-58011, CVE-2024-58016, CVE-2024-58020, CVE-2024-58056, CVE-2024-58058, CVE-2024-58061, CVE-2024-58086, CVE-2025-21645, CVE-2025-21648, CVE-2025-21655, CVE-2025-21676, CVE-2025-21682, CVE-2025-21702, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21718, CVE-2025-21731, CVE-2025-21745, CVE-2025-21758, CVE-2025-21760, CVE-2025-21764, CVE-2025-21765, CVE-2025-21780, CVE-2025-21795, CVE-2025-21796, CVE-2025-21802, CVE-2025-21814, CVE-2025-21846, CVE-2025-21853, CVE-2025-21861, CVE-2025-21864, CVE-2025-21867, CVE-2025-21875, CVE-2025-21887, CVE-2025-21913, CVE-2025-21919, CVE-2025-21925, CVE-2025-21926, CVE-2025-21938, CVE-2025-21959, CVE-2025-21999, CVE-2025-22005, CVE-2025-22015, CVE-2025-22055, CVE-2025-22056, CVE-2025-22060, CVE-2025-22083, CVE-2025-22090, CVE-2025-22095, CVE-2025-22107, CVE-2025-22111, CVE-2025-22121, CVE-2025-23136, CVE-2025-23143, CVE-2025-37785, CVE-2025-37909, CVE-2025-37917, CVE-2025-37945, CVE-2025-37959, CVE-2025-37964, CVE-2025-37972, CVE-2025-37980, CVE-2025-38125, CVE-2025-38162, CVE-2025-38192, CVE-2025-38201, CVE-2025-38232, CVE-2025-38322, CVE-2025-38591, CVE-2025-38614, CVE-2025-38681, CVE-2025-38704, CVE-2025-38721, CVE-2025-38725, CVE-2025-38727, CVE-2025-38732, CVE-2025-38736, CVE-2025-39681, CVE-2025-39691, CVE-2025-39721, CVE-2025-39748, CVE-2025-39756, CVE-2025-39764, CVE-2025-39770, CVE-2025-39773, CVE-2025-39782, CVE-2025-39795, CVE-2025-39826, CVE-2025-39827, CVE-2025-39845, CVE-2025-39866, CVE-2025-39871, CVE-2025-39931, CVE-2025-39953, CVE-2025-39955, CVE-2025-39964, CVE-2025-39977, CVE-2025-39978, CVE-2025-39980, CVE-2025-40022, CVE-2025-40070, CVE-2025-40078, CVE-2025-40080, CVE-2025-40105, CVE-2025-40135, CVE-2025-40149, CVE-2025-40219, CVE-2025-40261, CVE-2025-40300, CVE-2025-61984, CVE-2025-61985, CVE-2025-68206, CVE-2025-68261, CVE-2025-68264, CVE-2025-68265, CVE-2025-68266, CVE-2025-68291, CVE-2025-68337, CVE-2025-68349, CVE-2025-68363, CVE-2025-68371, CVE-2025-68724, CVE-2025-68725, CVE-2025-68742, CVE-2025-68764, CVE-2025-68773, CVE-2025-68776, CVE-2025-68782, CVE-2025-68787, CVE-2025-68788, CVE-2025-68798, CVE-2025-68803, CVE-2025-68814, CVE-2025-68816, CVE-2025-68818, CVE-2025-68820, CVE-2025-71064, CVE-2025-71075, CVE-2025-71079, CVE-2025-71085, CVE-2025-71086, CVE-2025-71088, CVE-2025-71095, CVE-2025-71097, CVE-2025-71098, CVE-2025-71104, CVE-2025-71112, CVE-2025-71113, CVE-2025-71114, CVE-2025-71120, CVE-2025-71123, CVE-2025-71131, CVE-2025-71161, CVE-2025-71162, CVE-2025-71163, CVE-2025-71185, CVE-2025-71186, CVE-2025-71189, CVE-2025-71190, CVE-2025-71191, CVE-2025-71197, CVE-2025-71221, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2026-3497, CVE-2026-22977, CVE-2026-22979, CVE-2026-22980, CVE-2026-22982, CVE-2026-22992, CVE-2026-22994, CVE-2026-23003, CVE-2026-23005, CVE-2026-23010, CVE-2026-23011, CVE-2026-23019, CVE-2026-23026, CVE-2026-23038, CVE-2026-23054, CVE-2026-23060, CVE-2026-23083, CVE-2026-23084, CVE-2026-23086, CVE-2026-23087, CVE-2026-23095, CVE-2026-23100, CVE-2026-23103, CVE-2026-23110, CVE-2026-23111, CVE-2026-23113, CVE-2026-23154, CVE-2026-23204, CVE-2026-23231, CVE-2026-23242, CVE-2026-23243, CVE-2026-23245, CVE-2026-23270, CVE-2026-23271, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23284, CVE-2026-23287, CVE-2026-23290, CVE-2026-23293, CVE-2026-23300, CVE-2026-23304, CVE-2026-23319, CVE-2026-23321, CVE-2026-23335, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23359, CVE-2026-23365, CVE-2026-23368, CVE-2026-23370, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23391, CVE-2026-23392, CVE-2026-23397, CVE-2026-23398, CVE-2026-23414, CVE-2026-23422, CVE-2026-23434, CVE-2026-23438, CVE-2026-23439, CVE-2026-23446, CVE-2026-23449, CVE-2026-23450, CVE-2026-23452, CVE-2026-23454, CVE-2026-23455, CVE-2026-23456, CVE-2026-23457, CVE-2026-23458, CVE-2026-23463, CVE-2026-23474, CVE-2026-23475, CVE-2026-27135, CVE-2026-31389, CVE-2026-31391, CVE-2026-31396, CVE-2026-31402, CVE-2026-31403, CVE-2026-31411, CVE-2026-31414, CVE-2026-31415, CVE-2026-31416, CVE-2026-31417, CVE-2026-31418, CVE-2026-31421, CVE-2026-31422, CVE-2026-31423, CVE-2026-31424, CVE-2026-31427, CVE-2026-31428, CVE-2026-31431, CVE-2026-31441, CVE-2026-31446, CVE-2026-31447, CVE-2026-31448, CVE-2026-31450, CVE-2026-31452, CVE-2026-31466, CVE-2026-31469, CVE-2026-31485, CVE-2026-31494, CVE-2026-31495, CVE-2026-31496, CVE-2026-31503, CVE-2026-31504, CVE-2026-31507, CVE-2026-31508, CVE-2026-31515, CVE-2026-31518, CVE-2026-31521, CVE-2026-31533, CVE-2026-31546, CVE-2026-31555, CVE-2026-31563, CVE-2026-31565, CVE-2026-31628, CVE-2026-31634, CVE-2026-31649, CVE-2026-31651, CVE-2026-31658, CVE-2026-31664, CVE-2026-31665, CVE-2026-31669, CVE-2026-31670, CVE-2026-31671, CVE-2026-31674, CVE-2026-31680, CVE-2026-31682, CVE-2026-31737, CVE-2026-31752, CVE-2026-31761, CVE-2026-31768, CVE-2026-40355, CVE-2026-41989, CVE-2026-43011, CVE-2026-43024, CVE-2026-43025, CVE-2026-43026, CVE-2026-43027, CVE-2026-43028, CVE-2026-43030, CVE-2026-43033, CVE-2026-43035, CVE-2026-43038, CVE-2026-43040, CVE-2026-43057, CVE-2026-43284, CVE-2026-46174, CVE-2026-46300 et CVE-2026-46333. | ||
| Siemens | N/A | Desigo CC toutes versions | ||
| Siemens | N/A | Desigo CC toutes versions pour la vulnérabilité CVE-2025-15467 |
| Title | Publication Time | Tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SIMATIC S7-PLCSIM Advanced toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-54429",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Desigo CC versions ant\u00e9rieures \u00e0 9.0.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 versions sup\u00e9rieures ou \u00e9gales \u00e03.1.6 pour les vuln\u00e9rabilit\u00e9s CVE-2021-41617, CVE-2023-28531, CVE-2023-51384, CVE-2023-52927, CVE-2024-26783, CVE-2024-27056, CVE-2024-28956, CVE-2024-36903, CVE-2024-36927, CVE-2024-42079, CVE-2024-46786, CVE-2024-47736, CVE-2024-47809, CVE-2024-49968, CVE-2024-49994, CVE-2024-49998, CVE-2024-50014, CVE-2024-50063, CVE-2024-50164, CVE-2024-50298, CVE-2024-53124, CVE-2024-53170, CVE-2024-54458, CVE-2024-56631, CVE-2024-56703, CVE-2024-56719, CVE-2024-57917, CVE-2024-57924, CVE-2024-57973, CVE-2024-57977, CVE-2024-57979, CVE-2024-58011, CVE-2024-58016, CVE-2024-58020, CVE-2024-58056, CVE-2024-58058, CVE-2024-58061, CVE-2024-58086, CVE-2025-21645, CVE-2025-21648, CVE-2025-21655, CVE-2025-21676, CVE-2025-21682, CVE-2025-21702, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21718, CVE-2025-21731, CVE-2025-21745, CVE-2025-21758, CVE-2025-21760, CVE-2025-21764, CVE-2025-21765, CVE-2025-21780, CVE-2025-21795, CVE-2025-21796, CVE-2025-21802, CVE-2025-21814, CVE-2025-21846, CVE-2025-21853, CVE-2025-21861, CVE-2025-21864, CVE-2025-21867, CVE-2025-21875, CVE-2025-21887, CVE-2025-21913, CVE-2025-21919, CVE-2025-21925, CVE-2025-21926, CVE-2025-21938, CVE-2025-21959, CVE-2025-21999, CVE-2025-22005, CVE-2025-22015, CVE-2025-22055, CVE-2025-22056, CVE-2025-22060, CVE-2025-22083, CVE-2025-22090, CVE-2025-22095, CVE-2025-22107, CVE-2025-22111, CVE-2025-22121, CVE-2025-23136, CVE-2025-23143, CVE-2025-37785, CVE-2025-37909, CVE-2025-37917, CVE-2025-37945, CVE-2025-37959, CVE-2025-37964, CVE-2025-37972, CVE-2025-37980, CVE-2025-38125, CVE-2025-38162, CVE-2025-38192, CVE-2025-38201, CVE-2025-38232, CVE-2025-38322, CVE-2025-38591, CVE-2025-38614, CVE-2025-38681, CVE-2025-38704, CVE-2025-38721, CVE-2025-38725, CVE-2025-38727, CVE-2025-38732, CVE-2025-38736, CVE-2025-39681, CVE-2025-39691, CVE-2025-39721, CVE-2025-39748, CVE-2025-39756, CVE-2025-39764, CVE-2025-39770, CVE-2025-39773, CVE-2025-39782, CVE-2025-39795, CVE-2025-39826, CVE-2025-39827, CVE-2025-39845, CVE-2025-39866, CVE-2025-39871, CVE-2025-39931, CVE-2025-39953, CVE-2025-39955, CVE-2025-39964, CVE-2025-39977, CVE-2025-39978, CVE-2025-39980, CVE-2025-40022, CVE-2025-40070, CVE-2025-40078, CVE-2025-40080, CVE-2025-40105, CVE-2025-40135, CVE-2025-40149, CVE-2025-40219, CVE-2025-40261, CVE-2025-40300, CVE-2025-61984, CVE-2025-61985, CVE-2025-68206, CVE-2025-68261, CVE-2025-68264, CVE-2025-68265, CVE-2025-68266, CVE-2025-68291, CVE-2025-68337, CVE-2025-68349, CVE-2025-68363, CVE-2025-68371, CVE-2025-68724, CVE-2025-68725, CVE-2025-68742, CVE-2025-68764, CVE-2025-68773, CVE-2025-68776, CVE-2025-68782, CVE-2025-68787, CVE-2025-68788, CVE-2025-68798, CVE-2025-68803, CVE-2025-68814, CVE-2025-68816, CVE-2025-68818, CVE-2025-68820, CVE-2025-71064, CVE-2025-71075, CVE-2025-71079, CVE-2025-71085, CVE-2025-71086, CVE-2025-71088, CVE-2025-71095, CVE-2025-71097, CVE-2025-71098, CVE-2025-71104, CVE-2025-71112, CVE-2025-71113, CVE-2025-71114, CVE-2025-71120, CVE-2025-71123, CVE-2025-71131, CVE-2025-71161, CVE-2025-71162, CVE-2025-71163, CVE-2025-71185, CVE-2025-71186, CVE-2025-71189, CVE-2025-71190, CVE-2025-71191, CVE-2025-71197, CVE-2025-71221, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2026-3497, CVE-2026-22977, CVE-2026-22979, CVE-2026-22980, CVE-2026-22982, CVE-2026-22992, CVE-2026-22994, CVE-2026-23003, CVE-2026-23005, CVE-2026-23010, CVE-2026-23011, CVE-2026-23019, CVE-2026-23026, CVE-2026-23038, CVE-2026-23054, CVE-2026-23060, CVE-2026-23083, CVE-2026-23084, CVE-2026-23086, CVE-2026-23087, CVE-2026-23095, CVE-2026-23100, CVE-2026-23103, CVE-2026-23110, CVE-2026-23111, CVE-2026-23113, CVE-2026-23154, CVE-2026-23204, CVE-2026-23231, CVE-2026-23242, CVE-2026-23243, CVE-2026-23245, CVE-2026-23270, CVE-2026-23271, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23284, CVE-2026-23287, CVE-2026-23290, CVE-2026-23293, CVE-2026-23300, CVE-2026-23304, CVE-2026-23319, CVE-2026-23321, CVE-2026-23335, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23359, CVE-2026-23365, CVE-2026-23368, CVE-2026-23370, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23391, CVE-2026-23392, CVE-2026-23397, CVE-2026-23398, CVE-2026-23414, CVE-2026-23422, CVE-2026-23434, CVE-2026-23438, CVE-2026-23439, CVE-2026-23446, CVE-2026-23449, CVE-2026-23450, CVE-2026-23452, CVE-2026-23454, CVE-2026-23455, CVE-2026-23456, CVE-2026-23457, CVE-2026-23458, CVE-2026-23463, CVE-2026-23474, CVE-2026-23475, CVE-2026-27135, CVE-2026-31389, CVE-2026-31391, CVE-2026-31396, CVE-2026-31402, CVE-2026-31403, CVE-2026-31411, CVE-2026-31414, CVE-2026-31415, CVE-2026-31416, CVE-2026-31417, CVE-2026-31418, CVE-2026-31421, CVE-2026-31422, CVE-2026-31423, CVE-2026-31424, CVE-2026-31427, CVE-2026-31428, CVE-2026-31431, CVE-2026-31441, CVE-2026-31446, CVE-2026-31447, CVE-2026-31448, CVE-2026-31450, CVE-2026-31452, CVE-2026-31466, CVE-2026-31469, CVE-2026-31485, CVE-2026-31494, CVE-2026-31495, CVE-2026-31496, CVE-2026-31503, CVE-2026-31504, CVE-2026-31507, CVE-2026-31508, CVE-2026-31515, CVE-2026-31518, CVE-2026-31521, CVE-2026-31533, CVE-2026-31546, CVE-2026-31555, CVE-2026-31563, CVE-2026-31565, CVE-2026-31628, CVE-2026-31634, CVE-2026-31649, CVE-2026-31651, CVE-2026-31658, CVE-2026-31664, CVE-2026-31665, CVE-2026-31669, CVE-2026-31670, CVE-2026-31671, CVE-2026-31674, CVE-2026-31680, CVE-2026-31682, CVE-2026-31737, CVE-2026-31752, CVE-2026-31761, CVE-2026-31768, CVE-2026-40355, CVE-2026-41989, CVE-2026-43011, CVE-2026-43024, CVE-2026-43025, CVE-2026-43026, CVE-2026-43027, CVE-2026-43028, CVE-2026-43030, CVE-2026-43033, CVE-2026-43035, CVE-2026-43038, CVE-2026-43040, CVE-2026-43057, CVE-2026-43284, CVE-2026-46174, CVE-2026-46300 et CVE-2026-46333.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Desigo CC toutes versions",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Desigo CC toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-15467",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
}
],
"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-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2026-27135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27135"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2025-22083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22083"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-38201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38201"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-31658",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31658"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2026-23368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23368"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2023-28531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28531"
},
{
"name": "CVE-2026-31485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31485"
},
{
"name": "CVE-2026-23475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23475"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2026-31402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31402"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-71265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71265"
},
{
"name": "CVE-2026-23450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23450"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-21853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21853"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2026-31416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31416"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2026-23438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23438"
},
{
"name": "CVE-2026-23293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23293"
},
{
"name": "CVE-2026-23463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23463"
},
{
"name": "CVE-2026-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23454"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2024-50014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50014"
},
{
"name": "CVE-2026-3497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3497"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2026-31448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31448"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-68773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68773"
},
{
"name": "CVE-2026-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"name": "CVE-2026-31752",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31752"
},
{
"name": "CVE-2026-40355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40355"
},
{
"name": "CVE-2024-26783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26783"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2026-43011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43011"
},
{
"name": "CVE-2023-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52927"
},
{
"name": "CVE-2026-31396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31396"
},
{
"name": "CVE-2024-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58061"
},
{
"name": "CVE-2026-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2025-21864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21864"
},
{
"name": "CVE-2026-23340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23340"
},
{
"name": "CVE-2024-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58056"
},
{
"name": "CVE-2025-71189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71189"
},
{
"name": "CVE-2025-71088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71088"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2026-43284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43284"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2026-23439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23439"
},
{
"name": "CVE-2025-22095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22095"
},
{
"name": "CVE-2026-43025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43025"
},
{
"name": "CVE-2026-23271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23271"
},
{
"name": "CVE-2024-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23434"
},
{
"name": "CVE-2026-31447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31447"
},
{
"name": "CVE-2026-31431",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31431"
},
{
"name": "CVE-2026-43028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43028"
},
{
"name": "CVE-2026-23422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23422"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-15467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15467"
},
{
"name": "CVE-2026-23304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23304"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2026-31546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31546"
},
{
"name": "CVE-2025-61985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61985"
},
{
"name": "CVE-2025-22055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22055"
},
{
"name": "CVE-2025-22090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22090"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2026-31389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31389"
},
{
"name": "CVE-2026-23456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23456"
},
{
"name": "CVE-2026-43033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43033"
},
{
"name": "CVE-2026-23287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23287"
},
{
"name": "CVE-2025-68291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68291"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2026-23457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23457"
},
{
"name": "CVE-2026-31496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31496"
},
{
"name": "CVE-2025-21655",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21655"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2025-21938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21938"
},
{
"name": "CVE-2026-43057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43057"
},
{
"name": "CVE-2025-21867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21867"
},
{
"name": "CVE-2024-49994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49994"
},
{
"name": "CVE-2026-43030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43030"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2026-23391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23391"
},
{
"name": "CVE-2026-31415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31415"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2026-31563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31563"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2026-23273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23273"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-41989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41989"
},
{
"name": "CVE-2026-23319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23319"
},
{
"name": "CVE-2026-23005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23005"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-31565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31565"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2026-23270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23270"
},
{
"name": "CVE-2025-21795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21795"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21645"
},
{
"name": "CVE-2026-31422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31422"
},
{
"name": "CVE-2026-23359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23359"
},
{
"name": "CVE-2026-31533",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31533"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2025-21758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21758"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2026-31418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31418"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-21706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21706"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2026-31427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31427"
},
{
"name": "CVE-2026-31555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31555"
},
{
"name": "CVE-2024-57917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57917"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2026-31515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31515"
},
{
"name": "CVE-2026-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2025-71267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71267"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2026-22994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22994"
},
{
"name": "CVE-2025-22056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22056"
},
{
"name": "CVE-2025-61984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61984"
},
{
"name": "CVE-2025-37964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37964"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2026-31423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31423"
},
{
"name": "CVE-2026-23370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23370"
},
{
"name": "CVE-2024-58086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58086"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2026-23414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23414"
},
{
"name": "CVE-2024-56631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56631"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2026-31669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31669"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-31671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31671"
},
{
"name": "CVE-2026-43024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43024"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-38322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38322"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2026-31628",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31628"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2024-27056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27056"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2026-31768",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31768"
},
{
"name": "CVE-2026-43026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43026"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2026-23446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23446"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2026-46300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46300"
},
{
"name": "CVE-2026-43035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43035"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2026-31665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31665"
},
{
"name": "CVE-2026-23300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23300"
},
{
"name": "CVE-2026-31391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31391"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2026-23243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23243"
},
{
"name": "CVE-2026-31521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31521"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2026-31634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31634"
},
{
"name": "CVE-2025-22060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22060"
},
{
"name": "CVE-2024-47736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47736"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-28956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28956"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37972"
},
{
"name": "CVE-2026-23379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23379"
},
{
"name": "CVE-2024-46786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46786"
},
{
"name": "CVE-2026-31421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31421"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2026-23381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23381"
},
{
"name": "CVE-2026-31518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31518"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2026-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-23245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23245"
},
{
"name": "CVE-2024-49998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49998"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2026-31403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31403"
},
{
"name": "CVE-2024-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53170"
},
{
"name": "CVE-2026-31504",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31504"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2026-23242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23242"
},
{
"name": "CVE-2024-54458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54458"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2025-39964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39964"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2026-23274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23274"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2026-31417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31417"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-21676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21676"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2026-43040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43040"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2026-23284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23284"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2026-23397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23397"
},
{
"name": "CVE-2025-21705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21705"
},
{
"name": "CVE-2026-23452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23452"
},
{
"name": "CVE-2026-23474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23474"
},
{
"name": "CVE-2025-40300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40300"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-23343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23343"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2026-31682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31682"
},
{
"name": "CVE-2026-23277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23277"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2026-31441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31441"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2026-23455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23455"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2026-23335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23335"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
},
{
"name": "CVE-2026-31495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31495"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2026-31507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31507"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2026-46333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46333"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2026-31411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31411"
},
{
"name": "CVE-2026-31428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31428"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2026-23449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23449"
},
{
"name": "CVE-2025-21648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21648"
},
{
"name": "CVE-2025-71266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71266"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-23458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23458"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2026-31649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31649"
},
{
"name": "CVE-2026-31674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31674"
},
{
"name": "CVE-2026-43027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43027"
},
{
"name": "CVE-2025-71123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71123"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2026-23010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23010"
},
{
"name": "CVE-2026-54429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-54429"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2026-23321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23321"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2026-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2026-31503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31503"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2026-23378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23378"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-38736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38736"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2023-51384",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51384"
},
{
"name": "CVE-2021-41617",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41617"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2026-31446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31446"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2026-31508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31508"
},
{
"name": "CVE-2026-23365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23365"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2026-31424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31424"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2026-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"name": "CVE-2025-40022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40022"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2026-23351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23351"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-07-15T00:00:00",
"last_revision_date": "2026-07-15T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0880",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-07-15T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"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 les produits Siemens. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits Siemens",
"vendor_advisories": [
{
"published_at": "2026-07-14",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-828211",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-828211.html"
},
{
"published_at": "2026-07-14",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-019113",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"published_at": "2026-07-14",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-734552",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-734552.html"
}
]
}
CERTFR-2026-AVI-1298
Vulnerability from certfr_avis - Published: 2026-10-13 - Updated: 2026-10-13
De multiples vulnérabilités ont été découvertes dans les produits Siemens. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1514SPT-2 PN (6ES7514-2VN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC S7 PLCs Web Server toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1514SP F-2 PN (6ES7514-2SN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel hygienic (6AV2128-3UB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3XB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC S7 Webserver API versions antérieures à 3.3.62 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel neutral design (6AV2128-3UB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC WinCC V8.1 versions antérieures à 8.1.7 | ||
| Siemens | SIMATIC | SIMATIC IPC127E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3QB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel hygienic (6AV2128-3MB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SCALANCE | SCALANCE LPE9413 (6GK5998-3GS01-2AC2) toutes versions pour la vulnérabilité CVE-2026-44414 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DK03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Windows OS toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3MB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC427E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC S7-1500 versions supérieures ou égales à3.1.7 pour les vulnérabilités CVE-2021-41617, CVE-2023-28531, CVE-2023-51384, CVE-2023-52927, CVE-2023-53292, CVE-2024-26783, CVE-2024-27056, CVE-2024-28956, CVE-2024-36903, CVE-2024-36927, CVE-2024-42079, CVE-2024-46786, CVE-2024-47736, CVE-2024-47809, CVE-2024-49968, CVE-2024-49994, CVE-2024-49998, CVE-2024-50014, CVE-2024-50063, CVE-2024-50164, CVE-2024-50298, CVE-2024-53124, CVE-2024-53170, CVE-2024-54458, CVE-2024-56631, CVE-2024-56703, CVE-2024-56719, CVE-2024-57917, CVE-2024-57924, CVE-2024-57973, CVE-2024-57977, CVE-2024-57979, CVE-2024-58011, CVE-2024-58016, CVE-2024-58020, CVE-2024-58056, CVE-2024-58058, CVE-2024-58061, CVE-2024-58086, CVE-2025-21645, CVE-2025-21648, CVE-2025-21655, CVE-2025-21676, CVE-2025-21682, CVE-2025-21702, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21718, CVE-2025-21731, CVE-2025-21745, CVE-2025-21758, CVE-2025-21760, CVE-2025-21764, CVE-2025-21765, CVE-2025-21780, CVE-2025-21795, CVE-2025-21796, CVE-2025-21802, CVE-2025-21814, CVE-2025-21846, CVE-2025-21853, CVE-2025-21861, CVE-2025-21863, CVE-2025-21864, CVE-2025-21867, CVE-2025-21875, CVE-2025-21887, CVE-2025-21913, CVE-2025-21919, CVE-2025-21925, CVE-2025-21926, CVE-2025-21938, CVE-2025-21959, CVE-2025-21999, CVE-2025-22005, CVE-2025-22015, CVE-2025-22055, CVE-2025-22056, CVE-2025-22060, CVE-2025-22083, CVE-2025-22090, CVE-2025-22095, CVE-2025-22107, CVE-2025-22111, CVE-2025-22121, CVE-2025-23136, CVE-2025-23143, CVE-2025-37785, CVE-2025-37909, CVE-2025-37917, CVE-2025-37945, CVE-2025-37959, CVE-2025-37964, CVE-2025-37972, CVE-2025-37980, CVE-2025-38125, CVE-2025-38162, CVE-2025-38192, CVE-2025-38201, CVE-2025-38232, CVE-2025-38322, CVE-2025-38591, CVE-2025-38614, CVE-2025-38681, CVE-2025-38704, CVE-2025-38721, CVE-2025-38725, CVE-2025-38727, CVE-2025-38732, CVE-2025-38736, CVE-2025-39681, CVE-2025-39691, CVE-2025-39721, CVE-2025-39748, CVE-2025-39756, CVE-2025-39764, CVE-2025-39770, CVE-2025-39773, CVE-2025-39782, CVE-2025-39795, CVE-2025-39826, CVE-2025-39827, CVE-2025-39845, CVE-2025-39866, CVE-2025-39871, CVE-2025-39931, CVE-2025-39953, CVE-2025-39955, CVE-2025-39964, CVE-2025-39977, CVE-2025-39978, CVE-2025-39980, CVE-2025-40022, CVE-2025-40070, CVE-2025-40078, CVE-2025-40080, CVE-2025-40105, CVE-2025-40135, CVE-2025-40149, CVE-2025-40196, CVE-2025-40219, CVE-2025-40261, CVE-2025-40300, CVE-2025-61984, CVE-2025-61985, CVE-2025-68206, CVE-2025-68261, CVE-2025-68264, CVE-2025-68265, CVE-2025-68266, CVE-2025-68291, CVE-2025-68337, CVE-2025-68349, CVE-2025-68363, CVE-2025-68371, CVE-2025-68724, CVE-2025-68725, CVE-2025-68742, CVE-2025-68764, CVE-2025-68773, CVE-2025-68776, CVE-2025-68782, CVE-2025-68787, CVE-2025-68788, CVE-2025-68798, CVE-2025-68803, CVE-2025-68814, CVE-2025-68816, CVE-2025-68818, CVE-2025-68820, CVE-2025-71064, CVE-2025-71075, CVE-2025-71079, CVE-2025-71085, CVE-2025-71086, CVE-2025-71088, CVE-2025-71095, CVE-2025-71097, CVE-2025-71098, CVE-2025-71104, CVE-2025-71112, CVE-2025-71113, CVE-2025-71114, CVE-2025-71120, CVE-2025-71123, CVE-2025-71131, CVE-2025-71161, CVE-2025-71162, CVE-2025-71163, CVE-2025-71185, CVE-2025-71186, CVE-2025-71189, CVE-2025-71190, CVE-2025-71191, CVE-2025-71197, CVE-2025-71221, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2026-3497, CVE-2026-22977, CVE-2026-22979, CVE-2026-22980, CVE-2026-22982, CVE-2026-22992, CVE-2026-22994, CVE-2026-23003, CVE-2026-23005, CVE-2026-23010, CVE-2026-23011, CVE-2026-23019, CVE-2026-23026, CVE-2026-23038, CVE-2026-23054, CVE-2026-23060, CVE-2026-23083, CVE-2026-23084, CVE-2026-23086, CVE-2026-23087, CVE-2026-23095, CVE-2026-23100, CVE-2026-23103, CVE-2026-23110, CVE-2026-23111, CVE-2026-23113, CVE-2026-23154, CVE-2026-23204, CVE-2026-23231, CVE-2026-23242, CVE-2026-23243, CVE-2026-23245, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23284, CVE-2026-23287, CVE-2026-23290, CVE-2026-23293, CVE-2026-23300, CVE-2026-23304, CVE-2026-23319, CVE-2026-23321, CVE-2026-23335, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23359, CVE-2026-23365, CVE-2026-23368, CVE-2026-23370, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23391, CVE-2026-23392, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23414, CVE-2026-23422, CVE-2026-23434, CVE-2026-23438, CVE-2026-23439, CVE-2026-23446, CVE-2026-23449, CVE-2026-23450, CVE-2026-23452, CVE-2026-23454, CVE-2026-23455, CVE-2026-23456, CVE-2026-23457, CVE-2026-23458, CVE-2026-23463, CVE-2026-23474, CVE-2026-23475, CVE-2026-27135, CVE-2026-31389, CVE-2026-31391, CVE-2026-31396, CVE-2026-31402, CVE-2026-31403, CVE-2026-31411, CVE-2026-31414, CVE-2026-31415, CVE-2026-31416, CVE-2026-31417, CVE-2026-31418, CVE-2026-31421, CVE-2026-31422, CVE-2026-31423, CVE-2026-31424, CVE-2026-31427, CVE-2026-31428, CVE-2026-31441, CVE-2026-31446, CVE-2026-31447, CVE-2026-31448, CVE-2026-31449, CVE-2026-31450, CVE-2026-31452, CVE-2026-31466, CVE-2026-31469, CVE-2026-31485, CVE-2026-31494, CVE-2026-31495, CVE-2026-31496, CVE-2026-31503, CVE-2026-31504, CVE-2026-31507, CVE-2026-31508, CVE-2026-31515, CVE-2026-31518, CVE-2026-31521, CVE-2026-31533, CVE-2026-31546, CVE-2026-31555, CVE-2026-31563, CVE-2026-31565, CVE-2026-31628, CVE-2026-31634, CVE-2026-31649, CVE-2026-31651, CVE-2026-31658, CVE-2026-31664, CVE-2026-31665, CVE-2026-31669, CVE-2026-31670, CVE-2026-31671, CVE-2026-31674, CVE-2026-31680, CVE-2026-31681, CVE-2026-31682, CVE-2026-31700, CVE-2026-31737, CVE-2026-31752, CVE-2026-31761, CVE-2026-31768, CVE-2026-40355, CVE-2026-41989, CVE-2026-43011, CVE-2026-43024, CVE-2026-43025, CVE-2026-43026, CVE-2026-43027, CVE-2026-43028, CVE-2026-43030, CVE-2026-43033, CVE-2026-43035, CVE-2026-43038, CVE-2026-43040, CVE-2026-43057, CVE-2026-43071, CVE-2026-43085, CVE-2026-43089, CVE-2026-43116, CVE-2026-43216, CVE-2026-43303, CVE-2026-43492, CVE-2026-43499, CVE-2026-43501, CVE-2026-45841, CVE-2026-46015, CVE-2026-46021, CVE-2026-46033, CVE-2026-46037, CVE-2026-46040, CVE-2026-46046, CVE-2026-46086, CVE-2026-46101, CVE-2026-46116, CVE-2026-46132, CVE-2026-46172, CVE-2026-46173, CVE-2026-46174, CVE-2026-46193, CVE-2026-46303, CVE-2026-46306, CVE-2026-46323, CVE-2026-46333, CVE-2026-52910, CVE-2026-52912, CVE-2026-52930, CVE-2026-52933, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52970, CVE-2026-52986, CVE-2026-52998, CVE-2026-52999, CVE-2026-53001, CVE-2026-53002, CVE-2026-53006, CVE-2026-53012, CVE-2026-53050, CVE-2026-53134, CVE-2026-53218, CVE-2026-53219, CVE-2026-53223, CVE-2026-53236, CVE-2026-53239, CVE-2026-53249, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53295, CVE-2026-53352, CVE-2026-53400, CVE-2026-63810, CVE-2026-64279, CVE-2026-64317, CVE-2026-64370, CVE-2026-64371, CVE-2026-64375, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64538, CVE-2026-64545, CVE-2026-64552 et CVE-2026-64560. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3XB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel hygienic (6AV2128-3QB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DM03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3UB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1514SP-2 PN (6ES7514-2DN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel neutral design (6AV2128-3QB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000, Unified Comfort Panel neutral (6AV2128-3KB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC WinCC V7.5 toutes versions pour la vulnérabilité CVE-2026-59241 | ||
| Siemens | SIMATIC | SIMATIC WinCC V8.0 versions antérieures à 8.0.0.11 | ||
| Siemens | SIMATIC | SIMATIC IoT2050 Advanced IED (6ES7647-0BW00-1YA2) versions antérieures à 1.28.1.2 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3QB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel hygienic neutral design (6AV2128-3QB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC227E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000 Unified Comfort Panel hygienic neutral design (6AV2128-3KB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3UB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Hygienic (6AV2128-3XB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SM03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel hygienic neutral design (6AV2128-3MB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3XB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC227G / IPC277G / IPC277G PRO / IPC327G / IPC377G versions antérieures à 28.01.15 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3UB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3UB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC IPC BX-21A Industrial Edge Device versions antérieures à 1.28.1.2 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700 Unified Comfort Panel (6AV2128-3GB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3QB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel (6AV2128-3MB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel (6AV2128-3UB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC227G Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC S7 Webserver API versions antérieures à 3.3.61 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3UB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | Desigo | Desigo PXC/PXM versions supérieures ou égales à2.3. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2026-89208. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel (6AV2128-3QB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3UB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3XB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V2 CPUs - Windows OS toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC (incl. SIPLUS variants) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3XB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC Drive Controller CPU 1507D TF (6ES7615-7DF10-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3MB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC S7-1500 TM MFP toutes versions pour les vulnérabilités CVE-2023-52927, CVE-2023-53292, CVE-2023-54271, CVE-2024-26982, CVE-2024-36922, CVE-2024-40945, CVE-2024-47809, CVE-2024-49998, CVE-2024-53166, CVE-2024-56647, CVE-2024-56657, CVE-2024-56719, CVE-2024-57977, CVE-2024-57979, CVE-2024-57980, CVE-2024-57981, CVE-2024-57986, CVE-2024-57993, CVE-2024-57996, CVE-2024-58002, CVE-2024-58005, CVE-2024-58009, CVE-2024-58013, CVE-2024-58014, CVE-2024-58017, CVE-2024-58020, CVE-2024-58058, CVE-2024-58061, CVE-2024-58063, CVE-2024-58068, CVE-2024-58071, CVE-2024-58072, CVE-2024-58077, CVE-2024-58079, CVE-2024-58083, CVE-2025-21682, CVE-2025-21700, CVE-2025-21702, CVE-2025-21703, CVE-2025-21704, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21708, CVE-2025-21716, CVE-2025-21719, CVE-2025-21724, CVE-2025-21725, CVE-2025-21726, CVE-2025-21727, CVE-2025-21728, CVE-2025-21731, CVE-2025-21735, CVE-2025-21738, CVE-2025-21744, CVE-2025-21745, CVE-2025-21753, CVE-2025-21756, CVE-2025-21758, CVE-2025-21760, CVE-2025-21761, CVE-2025-21762, CVE-2025-21763, CVE-2025-21764, CVE-2025-21765, CVE-2025-21766, CVE-2025-21767, CVE-2025-21776, CVE-2025-21779, CVE-2025-21787, CVE-2025-21790, CVE-2025-21791, CVE-2025-21795, CVE-2025-21796, CVE-2025-21806, CVE-2025-21814, CVE-2025-21830, CVE-2025-21832, CVE-2025-21835, CVE-2025-21838, CVE-2025-21844, CVE-2025-21846, CVE-2025-21858, CVE-2025-21859, CVE-2025-21862, CVE-2025-21863, CVE-2025-21864, CVE-2025-21865, CVE-2025-22105, CVE-2025-23131, CVE-2025-38105, CVE-2025-38162, CVE-2025-38192, CVE-2025-38250, CVE-2025-38584, CVE-2025-38704, CVE-2025-39748, CVE-2025-39863, CVE-2025-39997, CVE-2025-40135, CVE-2025-68206, CVE-2025-68239, CVE-2025-68265, CVE-2026-23066, CVE-2026-23100, CVE-2026-23113, CVE-2026-23141, CVE-2026-23154, CVE-2026-23157, CVE-2026-23204, CVE-2026-23231, CVE-2026-23245, CVE-2026-23253, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23272, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23278, CVE-2026-23279, CVE-2026-23281, CVE-2026-23290, CVE-2026-23291, CVE-2026-23292, CVE-2026-23296, CVE-2026-23300, CVE-2026-23302, CVE-2026-23303, CVE-2026-23304, CVE-2026-23310, CVE-2026-23312, CVE-2026-23315, CVE-2026-23317, CVE-2026-23318, CVE-2026-23319, CVE-2026-23321, CVE-2026-23336, CVE-2026-23339, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23352, CVE-2026-23356, CVE-2026-23357, CVE-2026-23359, CVE-2026-23364, CVE-2026-23365, CVE-2026-23367, CVE-2026-23368, CVE-2026-23370, CVE-2026-23372, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23382, CVE-2026-23388, CVE-2026-23389, CVE-2026-23391, CVE-2026-23392, CVE-2026-23395, CVE-2026-23396, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23442, CVE-2026-23444, CVE-2026-31407, CVE-2026-31449, CVE-2026-31451, CVE-2026-31488, CVE-2026-31500, CVE-2026-31532, CVE-2026-31580, CVE-2026-31583, CVE-2026-31586, CVE-2026-31611, CVE-2026-31612, CVE-2026-31613, CVE-2026-31617, CVE-2026-31622, CVE-2026-31624, CVE-2026-31625, CVE-2026-31629, CVE-2026-31630, CVE-2026-31637, CVE-2026-31642, CVE-2026-31673, CVE-2026-31676, CVE-2026-31681, CVE-2026-31685, CVE-2026-31694, CVE-2026-31696, CVE-2026-31697, CVE-2026-31698, CVE-2026-31699, CVE-2026-31700, CVE-2026-31704, CVE-2026-31705, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-43052, CVE-2026-43071, CVE-2026-43074, CVE-2026-43080, CVE-2026-43085, CVE-2026-43089, CVE-2026-43093, CVE-2026-43094, CVE-2026-43099, CVE-2026-43110, CVE-2026-43111, CVE-2026-43112, CVE-2026-43114, CVE-2026-43116, CVE-2026-43117, CVE-2026-43303, CVE-2026-43350, CVE-2026-43421, CVE-2026-43492, CVE-2026-43493, CVE-2026-43496, CVE-2026-43499, CVE-2026-43502, CVE-2026-43503, CVE-2026-45834, CVE-2026-45835, CVE-2026-45836, CVE-2026-45838, CVE-2026-45839, CVE-2026-45840, CVE-2026-45841, CVE-2026-45842, CVE-2026-45843, CVE-2026-45844, CVE-2026-45850, CVE-2026-45991, CVE-2026-45997, CVE-2026-46003, CVE-2026-46015, CVE-2026-46018, CVE-2026-46021, CVE-2026-46022, CVE-2026-46023, CVE-2026-46026, CVE-2026-46033, CVE-2026-46037, CVE-2026-46038, CVE-2026-46040, CVE-2026-46044, CVE-2026-46046, CVE-2026-46047, CVE-2026-46050, CVE-2026-46051, CVE-2026-46056, CVE-2026-46064, CVE-2026-46065, CVE-2026-46069, CVE-2026-46070, CVE-2026-46083, CVE-2026-46086, CVE-2026-46088, CVE-2026-46092, CVE-2026-46099, CVE-2026-46101, CVE-2026-46102, CVE-2026-46107, CVE-2026-46110, CVE-2026-46113, CVE-2026-46116, CVE-2026-46120, CVE-2026-46122, CVE-2026-46124, CVE-2026-46125, CVE-2026-46128, CVE-2026-46136, CVE-2026-46137, CVE-2026-46146, CVE-2026-46149, CVE-2026-46150, CVE-2026-46151, CVE-2026-46159, CVE-2026-46161, CVE-2026-46163, CVE-2026-46165, CVE-2026-46167, CVE-2026-46168, CVE-2026-46172, CVE-2026-46173, CVE-2026-46177, CVE-2026-46180, CVE-2026-46185, CVE-2026-46187, CVE-2026-46190, CVE-2026-46191, CVE-2026-46193, CVE-2026-46195, CVE-2026-46196, CVE-2026-46209, CVE-2026-46214, CVE-2026-46227, CVE-2026-46234, CVE-2026-46243, CVE-2026-46275, CVE-2026-46294, CVE-2026-46303, CVE-2026-46304, CVE-2026-46306, CVE-2026-46307, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-46323, CVE-2026-46331, CVE-2026-52909, CVE-2026-52910, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52947, CVE-2026-52948, CVE-2026-53080, CVE-2026-53131, CVE-2026-53146, CVE-2026-53147, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53167, CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53183, CVE-2026-53184, CVE-2026-53192, CVE-2026-53198, CVE-2026-53208, CVE-2026-53212, CVE-2026-53218, CVE-2026-53219, CVE-2026-53221, CVE-2026-53225, CVE-2026-53227, CVE-2026-53228, CVE-2026-53236, CVE-2026-53239, CVE-2026-53242, CVE-2026-53245, CVE-2026-53249, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53325, CVE-2026-53337, CVE-2026-53349, CVE-2026-53350, CVE-2026-53352, CVE-2026-53356, CVE-2026-53358, CVE-2026-53362 et CVE-2026-64560. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel hygienic neutral design (6AV2128-3UB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC BX-59A Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700, Unified Comfort Panel neutral design (6AV2128-3GB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC3 V4 CPUs toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3QB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000 Unified Comfort Panel hygienic (6AV2128-3KB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SK03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Panel neutral design (6AV2128-3XB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IoT2050 SM IED (6ES7647-0CW00-1AA2) versions antérieures à 1.28.1.2 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3QB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel neutral design (6AV2128-3MB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3MB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC BX-21A versions antérieures à 31.01.13 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3MB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC RW-543A versions antérieures à 1.1.4 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3XB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SCALANCE | SCALANCE LPE9433 (6GK5998-3GS11-2AC2) toutes versions pour la vulnérabilité CVE-2026-44414 | ||
| Siemens | SIMATIC | SIMATIC IPC847E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3QB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000 Unified Comfort Panel (6AV2128-3KB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1514SPT F-2 PN (6ES7514-2WN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3MB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Industrial OS toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC IPC BX-39A Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Hygienic neutral design (6AV2128-3XB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3MB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC Drive Controller CPU 1504D TF (6ES7615-4DF10-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Panel (6AV2128-3XB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SIMATIC ET 200SP CPU 1514SPT-2 PN (6ES7514-2VN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 PLCs Web Server toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1514SP F-2 PN (6ES7514-2SN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel hygienic (6AV2128-3UB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3XB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 Webserver API versions ant\u00e9rieures \u00e0 3.3.62",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel neutral design (6AV2128-3UB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V8.1 versions ant\u00e9rieures \u00e0 8.1.7",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC127E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3QB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel hygienic (6AV2128-3MB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE LPE9413 (6GK5998-3GS01-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44414",
"product": {
"name": "SCALANCE",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DK03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Windows OS toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3MB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC427E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 versions sup\u00e9rieures ou \u00e9gales \u00e03.1.7 pour les vuln\u00e9rabilit\u00e9s CVE-2021-41617, CVE-2023-28531, CVE-2023-51384, CVE-2023-52927, CVE-2023-53292, CVE-2024-26783, CVE-2024-27056, CVE-2024-28956, CVE-2024-36903, CVE-2024-36927, CVE-2024-42079, CVE-2024-46786, CVE-2024-47736, CVE-2024-47809, CVE-2024-49968, CVE-2024-49994, CVE-2024-49998, CVE-2024-50014, CVE-2024-50063, CVE-2024-50164, CVE-2024-50298, CVE-2024-53124, CVE-2024-53170, CVE-2024-54458, CVE-2024-56631, CVE-2024-56703, CVE-2024-56719, CVE-2024-57917, CVE-2024-57924, CVE-2024-57973, CVE-2024-57977, CVE-2024-57979, CVE-2024-58011, CVE-2024-58016, CVE-2024-58020, CVE-2024-58056, CVE-2024-58058, CVE-2024-58061, CVE-2024-58086, CVE-2025-21645, CVE-2025-21648, CVE-2025-21655, CVE-2025-21676, CVE-2025-21682, CVE-2025-21702, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21718, CVE-2025-21731, CVE-2025-21745, CVE-2025-21758, CVE-2025-21760, CVE-2025-21764, CVE-2025-21765, CVE-2025-21780, CVE-2025-21795, CVE-2025-21796, CVE-2025-21802, CVE-2025-21814, CVE-2025-21846, CVE-2025-21853, CVE-2025-21861, CVE-2025-21863, CVE-2025-21864, CVE-2025-21867, CVE-2025-21875, CVE-2025-21887, CVE-2025-21913, CVE-2025-21919, CVE-2025-21925, CVE-2025-21926, CVE-2025-21938, CVE-2025-21959, CVE-2025-21999, CVE-2025-22005, CVE-2025-22015, CVE-2025-22055, CVE-2025-22056, CVE-2025-22060, CVE-2025-22083, CVE-2025-22090, CVE-2025-22095, CVE-2025-22107, CVE-2025-22111, CVE-2025-22121, CVE-2025-23136, CVE-2025-23143, CVE-2025-37785, CVE-2025-37909, CVE-2025-37917, CVE-2025-37945, CVE-2025-37959, CVE-2025-37964, CVE-2025-37972, CVE-2025-37980, CVE-2025-38125, CVE-2025-38162, CVE-2025-38192, CVE-2025-38201, CVE-2025-38232, CVE-2025-38322, CVE-2025-38591, CVE-2025-38614, CVE-2025-38681, CVE-2025-38704, CVE-2025-38721, CVE-2025-38725, CVE-2025-38727, CVE-2025-38732, CVE-2025-38736, CVE-2025-39681, CVE-2025-39691, CVE-2025-39721, CVE-2025-39748, CVE-2025-39756, CVE-2025-39764, CVE-2025-39770, CVE-2025-39773, CVE-2025-39782, CVE-2025-39795, CVE-2025-39826, CVE-2025-39827, CVE-2025-39845, CVE-2025-39866, CVE-2025-39871, CVE-2025-39931, CVE-2025-39953, CVE-2025-39955, CVE-2025-39964, CVE-2025-39977, CVE-2025-39978, CVE-2025-39980, CVE-2025-40022, CVE-2025-40070, CVE-2025-40078, CVE-2025-40080, CVE-2025-40105, CVE-2025-40135, CVE-2025-40149, CVE-2025-40196, CVE-2025-40219, CVE-2025-40261, CVE-2025-40300, CVE-2025-61984, CVE-2025-61985, CVE-2025-68206, CVE-2025-68261, CVE-2025-68264, CVE-2025-68265, CVE-2025-68266, CVE-2025-68291, CVE-2025-68337, CVE-2025-68349, CVE-2025-68363, CVE-2025-68371, CVE-2025-68724, CVE-2025-68725, CVE-2025-68742, CVE-2025-68764, CVE-2025-68773, CVE-2025-68776, CVE-2025-68782, CVE-2025-68787, CVE-2025-68788, CVE-2025-68798, CVE-2025-68803, CVE-2025-68814, CVE-2025-68816, CVE-2025-68818, CVE-2025-68820, CVE-2025-71064, CVE-2025-71075, CVE-2025-71079, CVE-2025-71085, CVE-2025-71086, CVE-2025-71088, CVE-2025-71095, CVE-2025-71097, CVE-2025-71098, CVE-2025-71104, CVE-2025-71112, CVE-2025-71113, CVE-2025-71114, CVE-2025-71120, CVE-2025-71123, CVE-2025-71131, CVE-2025-71161, CVE-2025-71162, CVE-2025-71163, CVE-2025-71185, CVE-2025-71186, CVE-2025-71189, CVE-2025-71190, CVE-2025-71191, CVE-2025-71197, CVE-2025-71221, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2026-3497, CVE-2026-22977, CVE-2026-22979, CVE-2026-22980, CVE-2026-22982, CVE-2026-22992, CVE-2026-22994, CVE-2026-23003, CVE-2026-23005, CVE-2026-23010, CVE-2026-23011, CVE-2026-23019, CVE-2026-23026, CVE-2026-23038, CVE-2026-23054, CVE-2026-23060, CVE-2026-23083, CVE-2026-23084, CVE-2026-23086, CVE-2026-23087, CVE-2026-23095, CVE-2026-23100, CVE-2026-23103, CVE-2026-23110, CVE-2026-23111, CVE-2026-23113, CVE-2026-23154, CVE-2026-23204, CVE-2026-23231, CVE-2026-23242, CVE-2026-23243, CVE-2026-23245, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23284, CVE-2026-23287, CVE-2026-23290, CVE-2026-23293, CVE-2026-23300, CVE-2026-23304, CVE-2026-23319, CVE-2026-23321, CVE-2026-23335, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23359, CVE-2026-23365, CVE-2026-23368, CVE-2026-23370, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23391, CVE-2026-23392, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23414, CVE-2026-23422, CVE-2026-23434, CVE-2026-23438, CVE-2026-23439, CVE-2026-23446, CVE-2026-23449, CVE-2026-23450, CVE-2026-23452, CVE-2026-23454, CVE-2026-23455, CVE-2026-23456, CVE-2026-23457, CVE-2026-23458, CVE-2026-23463, CVE-2026-23474, CVE-2026-23475, CVE-2026-27135, CVE-2026-31389, CVE-2026-31391, CVE-2026-31396, CVE-2026-31402, CVE-2026-31403, CVE-2026-31411, CVE-2026-31414, CVE-2026-31415, CVE-2026-31416, CVE-2026-31417, CVE-2026-31418, CVE-2026-31421, CVE-2026-31422, CVE-2026-31423, CVE-2026-31424, CVE-2026-31427, CVE-2026-31428, CVE-2026-31441, CVE-2026-31446, CVE-2026-31447, CVE-2026-31448, CVE-2026-31449, CVE-2026-31450, CVE-2026-31452, CVE-2026-31466, CVE-2026-31469, CVE-2026-31485, CVE-2026-31494, CVE-2026-31495, CVE-2026-31496, CVE-2026-31503, CVE-2026-31504, CVE-2026-31507, CVE-2026-31508, CVE-2026-31515, CVE-2026-31518, CVE-2026-31521, CVE-2026-31533, CVE-2026-31546, CVE-2026-31555, CVE-2026-31563, CVE-2026-31565, CVE-2026-31628, CVE-2026-31634, CVE-2026-31649, CVE-2026-31651, CVE-2026-31658, CVE-2026-31664, CVE-2026-31665, CVE-2026-31669, CVE-2026-31670, CVE-2026-31671, CVE-2026-31674, CVE-2026-31680, CVE-2026-31681, CVE-2026-31682, CVE-2026-31700, CVE-2026-31737, CVE-2026-31752, CVE-2026-31761, CVE-2026-31768, CVE-2026-40355, CVE-2026-41989, CVE-2026-43011, CVE-2026-43024, CVE-2026-43025, CVE-2026-43026, CVE-2026-43027, CVE-2026-43028, CVE-2026-43030, CVE-2026-43033, CVE-2026-43035, CVE-2026-43038, CVE-2026-43040, CVE-2026-43057, CVE-2026-43071, CVE-2026-43085, CVE-2026-43089, CVE-2026-43116, CVE-2026-43216, CVE-2026-43303, CVE-2026-43492, CVE-2026-43499, CVE-2026-43501, CVE-2026-45841, CVE-2026-46015, CVE-2026-46021, CVE-2026-46033, CVE-2026-46037, CVE-2026-46040, CVE-2026-46046, CVE-2026-46086, CVE-2026-46101, CVE-2026-46116, CVE-2026-46132, CVE-2026-46172, CVE-2026-46173, CVE-2026-46174, CVE-2026-46193, CVE-2026-46303, CVE-2026-46306, CVE-2026-46323, CVE-2026-46333, CVE-2026-52910, CVE-2026-52912, CVE-2026-52930, CVE-2026-52933, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52970, CVE-2026-52986, CVE-2026-52998, CVE-2026-52999, CVE-2026-53001, CVE-2026-53002, CVE-2026-53006, CVE-2026-53012, CVE-2026-53050, CVE-2026-53134, CVE-2026-53218, CVE-2026-53219, CVE-2026-53223, CVE-2026-53236, CVE-2026-53239, CVE-2026-53249, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53295, CVE-2026-53352, CVE-2026-53400, CVE-2026-63810, CVE-2026-64279, CVE-2026-64317, CVE-2026-64370, CVE-2026-64371, CVE-2026-64375, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64538, CVE-2026-64545, CVE-2026-64552 et CVE-2026-64560.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3XB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel hygienic (6AV2128-3QB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DM03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3UB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1514SP-2 PN (6ES7514-2DN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel neutral design (6AV2128-3QB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000, Unified Comfort Panel neutral (6AV2128-3KB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V7.5 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-59241",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V8.0 versions ant\u00e9rieures \u00e0 8.0.0.11",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IoT2050 Advanced IED (6ES7647-0BW00-1YA2) versions ant\u00e9rieures \u00e0 1.28.1.2",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3QB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel hygienic neutral design (6AV2128-3QB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC227E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel hygienic neutral design (6AV2128-3KB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3UB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Hygienic (6AV2128-3XB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SM03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel hygienic neutral design (6AV2128-3MB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3XB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC227G / IPC277G / IPC277G PRO / IPC327G / IPC377G versions ant\u00e9rieures \u00e0 28.01.15",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3UB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3UB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-21A Industrial Edge Device versions ant\u00e9rieures \u00e0 1.28.1.2",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel (6AV2128-3GB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3QB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel (6AV2128-3MB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel (6AV2128-3UB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC227G Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 Webserver API versions ant\u00e9rieures \u00e0 3.3.61",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3UB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Desigo PXC/PXM versions sup\u00e9rieures ou \u00e9gales \u00e02.3. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2026-89208.",
"product": {
"name": "Desigo",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel (6AV2128-3QB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3UB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3XB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V2 CPUs - Windows OS toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC (incl. SIPLUS variants) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3XB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Drive Controller CPU 1507D TF (6ES7615-7DF10-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3MB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 TM MFP toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2023-52927, CVE-2023-53292, CVE-2023-54271, CVE-2024-26982, CVE-2024-36922, CVE-2024-40945, CVE-2024-47809, CVE-2024-49998, CVE-2024-53166, CVE-2024-56647, CVE-2024-56657, CVE-2024-56719, CVE-2024-57977, CVE-2024-57979, CVE-2024-57980, CVE-2024-57981, CVE-2024-57986, CVE-2024-57993, CVE-2024-57996, CVE-2024-58002, CVE-2024-58005, CVE-2024-58009, CVE-2024-58013, CVE-2024-58014, CVE-2024-58017, CVE-2024-58020, CVE-2024-58058, CVE-2024-58061, CVE-2024-58063, CVE-2024-58068, CVE-2024-58071, CVE-2024-58072, CVE-2024-58077, CVE-2024-58079, CVE-2024-58083, CVE-2025-21682, CVE-2025-21700, CVE-2025-21702, CVE-2025-21703, CVE-2025-21704, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21708, CVE-2025-21716, CVE-2025-21719, CVE-2025-21724, CVE-2025-21725, CVE-2025-21726, CVE-2025-21727, CVE-2025-21728, CVE-2025-21731, CVE-2025-21735, CVE-2025-21738, CVE-2025-21744, CVE-2025-21745, CVE-2025-21753, CVE-2025-21756, CVE-2025-21758, CVE-2025-21760, CVE-2025-21761, CVE-2025-21762, CVE-2025-21763, CVE-2025-21764, CVE-2025-21765, CVE-2025-21766, CVE-2025-21767, CVE-2025-21776, CVE-2025-21779, CVE-2025-21787, CVE-2025-21790, CVE-2025-21791, CVE-2025-21795, CVE-2025-21796, CVE-2025-21806, CVE-2025-21814, CVE-2025-21830, CVE-2025-21832, CVE-2025-21835, CVE-2025-21838, CVE-2025-21844, CVE-2025-21846, CVE-2025-21858, CVE-2025-21859, CVE-2025-21862, CVE-2025-21863, CVE-2025-21864, CVE-2025-21865, CVE-2025-22105, CVE-2025-23131, CVE-2025-38105, CVE-2025-38162, CVE-2025-38192, CVE-2025-38250, CVE-2025-38584, CVE-2025-38704, CVE-2025-39748, CVE-2025-39863, CVE-2025-39997, CVE-2025-40135, CVE-2025-68206, CVE-2025-68239, CVE-2025-68265, CVE-2026-23066, CVE-2026-23100, CVE-2026-23113, CVE-2026-23141, CVE-2026-23154, CVE-2026-23157, CVE-2026-23204, CVE-2026-23231, CVE-2026-23245, CVE-2026-23253, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23272, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23278, CVE-2026-23279, CVE-2026-23281, CVE-2026-23290, CVE-2026-23291, CVE-2026-23292, CVE-2026-23296, CVE-2026-23300, CVE-2026-23302, CVE-2026-23303, CVE-2026-23304, CVE-2026-23310, CVE-2026-23312, CVE-2026-23315, CVE-2026-23317, CVE-2026-23318, CVE-2026-23319, CVE-2026-23321, CVE-2026-23336, CVE-2026-23339, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23352, CVE-2026-23356, CVE-2026-23357, CVE-2026-23359, CVE-2026-23364, CVE-2026-23365, CVE-2026-23367, CVE-2026-23368, CVE-2026-23370, CVE-2026-23372, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23382, CVE-2026-23388, CVE-2026-23389, CVE-2026-23391, CVE-2026-23392, CVE-2026-23395, CVE-2026-23396, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23442, CVE-2026-23444, CVE-2026-31407, CVE-2026-31449, CVE-2026-31451, CVE-2026-31488, CVE-2026-31500, CVE-2026-31532, CVE-2026-31580, CVE-2026-31583, CVE-2026-31586, CVE-2026-31611, CVE-2026-31612, CVE-2026-31613, CVE-2026-31617, CVE-2026-31622, CVE-2026-31624, CVE-2026-31625, CVE-2026-31629, CVE-2026-31630, CVE-2026-31637, CVE-2026-31642, CVE-2026-31673, CVE-2026-31676, CVE-2026-31681, CVE-2026-31685, CVE-2026-31694, CVE-2026-31696, CVE-2026-31697, CVE-2026-31698, CVE-2026-31699, CVE-2026-31700, CVE-2026-31704, CVE-2026-31705, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-43052, CVE-2026-43071, CVE-2026-43074, CVE-2026-43080, CVE-2026-43085, CVE-2026-43089, CVE-2026-43093, CVE-2026-43094, CVE-2026-43099, CVE-2026-43110, CVE-2026-43111, CVE-2026-43112, CVE-2026-43114, CVE-2026-43116, CVE-2026-43117, CVE-2026-43303, CVE-2026-43350, CVE-2026-43421, CVE-2026-43492, CVE-2026-43493, CVE-2026-43496, CVE-2026-43499, CVE-2026-43502, CVE-2026-43503, CVE-2026-45834, CVE-2026-45835, CVE-2026-45836, CVE-2026-45838, CVE-2026-45839, CVE-2026-45840, CVE-2026-45841, CVE-2026-45842, CVE-2026-45843, CVE-2026-45844, CVE-2026-45850, CVE-2026-45991, CVE-2026-45997, CVE-2026-46003, CVE-2026-46015, CVE-2026-46018, CVE-2026-46021, CVE-2026-46022, CVE-2026-46023, CVE-2026-46026, CVE-2026-46033, CVE-2026-46037, CVE-2026-46038, CVE-2026-46040, CVE-2026-46044, CVE-2026-46046, CVE-2026-46047, CVE-2026-46050, CVE-2026-46051, CVE-2026-46056, CVE-2026-46064, CVE-2026-46065, CVE-2026-46069, CVE-2026-46070, CVE-2026-46083, CVE-2026-46086, CVE-2026-46088, CVE-2026-46092, CVE-2026-46099, CVE-2026-46101, CVE-2026-46102, CVE-2026-46107, CVE-2026-46110, CVE-2026-46113, CVE-2026-46116, CVE-2026-46120, CVE-2026-46122, CVE-2026-46124, CVE-2026-46125, CVE-2026-46128, CVE-2026-46136, CVE-2026-46137, CVE-2026-46146, CVE-2026-46149, CVE-2026-46150, CVE-2026-46151, CVE-2026-46159, CVE-2026-46161, CVE-2026-46163, CVE-2026-46165, CVE-2026-46167, CVE-2026-46168, CVE-2026-46172, CVE-2026-46173, CVE-2026-46177, CVE-2026-46180, CVE-2026-46185, CVE-2026-46187, CVE-2026-46190, CVE-2026-46191, CVE-2026-46193, CVE-2026-46195, CVE-2026-46196, CVE-2026-46209, CVE-2026-46214, CVE-2026-46227, CVE-2026-46234, CVE-2026-46243, CVE-2026-46275, CVE-2026-46294, CVE-2026-46303, CVE-2026-46304, CVE-2026-46306, CVE-2026-46307, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-46323, CVE-2026-46331, CVE-2026-52909, CVE-2026-52910, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52947, CVE-2026-52948, CVE-2026-53080, CVE-2026-53131, CVE-2026-53146, CVE-2026-53147, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53167, CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53183, CVE-2026-53184, CVE-2026-53192, CVE-2026-53198, CVE-2026-53208, CVE-2026-53212, CVE-2026-53218, CVE-2026-53219, CVE-2026-53221, CVE-2026-53225, CVE-2026-53227, CVE-2026-53228, CVE-2026-53236, CVE-2026-53239, CVE-2026-53242, CVE-2026-53245, CVE-2026-53249, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53325, CVE-2026-53337, CVE-2026-53349, CVE-2026-53350, CVE-2026-53352, CVE-2026-53356, CVE-2026-53358, CVE-2026-53362 et CVE-2026-64560.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel hygienic neutral design (6AV2128-3UB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-59A Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700, Unified Comfort Panel neutral design (6AV2128-3GB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC3 V4 CPUs toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3QB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel hygienic (6AV2128-3KB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SK03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Panel neutral design (6AV2128-3XB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IoT2050 SM IED (6ES7647-0CW00-1AA2) versions ant\u00e9rieures \u00e0 1.28.1.2",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3QB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel neutral design (6AV2128-3MB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3MB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-21A versions ant\u00e9rieures \u00e0 31.01.13",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3MB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC RW-543A versions ant\u00e9rieures \u00e0 1.1.4",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3XB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE LPE9433 (6GK5998-3GS11-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44414",
"product": {
"name": "SCALANCE",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC847E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3QB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel (6AV2128-3KB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1514SPT F-2 PN (6ES7514-2WN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3MB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Industrial OS toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-39A Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Hygienic neutral design (6AV2128-3XB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3MB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Drive Controller CPU 1504D TF (6ES7615-4DF10-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Panel (6AV2128-3XB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
}
],
"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-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2026-45842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45842"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2026-63356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63356"
},
{
"name": "CVE-2026-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
},
{
"name": "CVE-2026-27135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27135"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2026-64552",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64552"
},
{
"name": "CVE-2026-53349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53349"
},
{
"name": "CVE-2025-39997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39997"
},
{
"name": "CVE-2026-64538",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64538"
},
{
"name": "CVE-2025-22083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22083"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-38201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38201"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-31658",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31658"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2026-23318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23318"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2026-53350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53350"
},
{
"name": "CVE-2026-23368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23368"
},
{
"name": "CVE-2026-46307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46307"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2026-52929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52929"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2023-28531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28531"
},
{
"name": "CVE-2026-31485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31485"
},
{
"name": "CVE-2026-23475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23475"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-46124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46124"
},
{
"name": "CVE-2026-64413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64413"
},
{
"name": "CVE-2026-43421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43421"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2026-31402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31402"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2026-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53218"
},
{
"name": "CVE-2026-63354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63354"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-71265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71265"
},
{
"name": "CVE-2026-23450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23450"
},
{
"name": "CVE-2026-23281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23281"
},
{
"name": "CVE-2026-31696",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31696"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-21853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21853"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2026-31704",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31704"
},
{
"name": "CVE-2026-31685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31685"
},
{
"name": "CVE-2026-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52970"
},
{
"name": "CVE-2026-31416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31416"
},
{
"name": "CVE-2026-43492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43492"
},
{
"name": "CVE-2024-58009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58009"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2026-46065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46065"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2026-44415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44415"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2023-54271",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54271"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2026-23438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23438"
},
{
"name": "CVE-2026-23293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23293"
},
{
"name": "CVE-2026-23463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23463"
},
{
"name": "CVE-2026-46185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46185"
},
{
"name": "CVE-2026-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23454"
},
{
"name": "CVE-2026-53400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53400"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2024-50014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50014"
},
{
"name": "CVE-2026-3497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3497"
},
{
"name": "CVE-2026-46064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46064"
},
{
"name": "CVE-2026-31698",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31698"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2026-46196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46196"
},
{
"name": "CVE-2026-31448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31448"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-68773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68773"
},
{
"name": "CVE-2026-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"name": "CVE-2026-31752",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31752"
},
{
"name": "CVE-2026-40355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40355"
},
{
"name": "CVE-2024-26783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26783"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2026-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53227"
},
{
"name": "CVE-2026-23303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23303"
},
{
"name": "CVE-2026-43011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43011"
},
{
"name": "CVE-2023-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52927"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"name": "CVE-2026-31396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31396"
},
{
"name": "CVE-2024-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58061"
},
{
"name": "CVE-2026-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53181"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2025-21864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21864"
},
{
"name": "CVE-2026-23340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23340"
},
{
"name": "CVE-2026-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52918"
},
{
"name": "CVE-2024-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58056"
},
{
"name": "CVE-2025-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23131"
},
{
"name": "CVE-2025-21725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21725"
},
{
"name": "CVE-2025-71189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71189"
},
{
"name": "CVE-2025-71088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71088"
},
{
"name": "CVE-2026-59241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59241"
},
{
"name": "CVE-2026-46303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46303"
},
{
"name": "CVE-2026-31613",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31613"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2026-64279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64279"
},
{
"name": "CVE-2026-89208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89208"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2026-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-23439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23439"
},
{
"name": "CVE-2025-22095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22095"
},
{
"name": "CVE-2026-23253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23253"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"name": "CVE-2026-43025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43025"
},
{
"name": "CVE-2026-31617",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31617"
},
{
"name": "CVE-2026-23271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23271"
},
{
"name": "CVE-2026-43052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43052"
},
{
"name": "CVE-2026-43496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43496"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2024-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-21779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21779"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2024-58005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58005"
},
{
"name": "CVE-2026-46173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46173"
},
{
"name": "CVE-2026-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46195"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"name": "CVE-2026-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53146"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23434"
},
{
"name": "CVE-2026-31711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31711"
},
{
"name": "CVE-2026-31611",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31611"
},
{
"name": "CVE-2026-63810",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63810"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2026-31447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31447"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-46092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46092"
},
{
"name": "CVE-2026-43028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43028"
},
{
"name": "CVE-2026-46040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46040"
},
{
"name": "CVE-2026-23422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23422"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2026-23304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23304"
},
{
"name": "CVE-2026-63352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63352"
},
{
"name": "CVE-2026-23357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23357"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2026-46137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46137"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53150"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2026-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53147"
},
{
"name": "CVE-2026-46159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46159"
},
{
"name": "CVE-2026-52942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
},
{
"name": "CVE-2026-31546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31546"
},
{
"name": "CVE-2026-46190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46190"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-61985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61985"
},
{
"name": "CVE-2026-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53183"
},
{
"name": "CVE-2026-31583",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31583"
},
{
"name": "CVE-2025-22055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22055"
},
{
"name": "CVE-2026-46209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46209"
},
{
"name": "CVE-2025-22090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22090"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2026-23317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23317"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2026-63351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63351"
},
{
"name": "CVE-2026-31389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31389"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2026-31681",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31681"
},
{
"name": "CVE-2026-23456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23456"
},
{
"name": "CVE-2026-43033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43033"
},
{
"name": "CVE-2026-23287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23287"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2025-68291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68291"
},
{
"name": "CVE-2026-31622",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31622"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2026-23457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23457"
},
{
"name": "CVE-2026-43503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43503"
},
{
"name": "CVE-2026-46101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46101"
},
{
"name": "CVE-2025-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21830"
},
{
"name": "CVE-2026-46099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46099"
},
{
"name": "CVE-2026-31496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31496"
},
{
"name": "CVE-2026-31642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31642"
},
{
"name": "CVE-2026-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-43350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43350"
},
{
"name": "CVE-2026-44414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44414"
},
{
"name": "CVE-2025-21655",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21655"
},
{
"name": "CVE-2025-21767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21767"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2026-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53149"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2026-46037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46037"
},
{
"name": "CVE-2026-46116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46116"
},
{
"name": "CVE-2025-21838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21838"
},
{
"name": "CVE-2025-21938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21938"
},
{
"name": "CVE-2026-43057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43057"
},
{
"name": "CVE-2025-21867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21867"
},
{
"name": "CVE-2026-43117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43117"
},
{
"name": "CVE-2024-49994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49994"
},
{
"name": "CVE-2026-46083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46083"
},
{
"name": "CVE-2026-43030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43030"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2026-43074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43074"
},
{
"name": "CVE-2026-46151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46151"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2026-23391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23391"
},
{
"name": "CVE-2026-31415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31415"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2026-31563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31563"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2026-23273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23273"
},
{
"name": "CVE-2026-23372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23372"
},
{
"name": "CVE-2026-43080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43080"
},
{
"name": "CVE-2026-46146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46146"
},
{
"name": "CVE-2026-45836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45836"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-41989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41989"
},
{
"name": "CVE-2026-23319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23319"
},
{
"name": "CVE-2026-23005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23005"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2026-64375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64375"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-31565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31565"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2026-31697",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31697"
},
{
"name": "CVE-2026-23270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23270"
},
{
"name": "CVE-2026-63350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63350"
},
{
"name": "CVE-2026-46069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46069"
},
{
"name": "CVE-2026-64370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64370"
},
{
"name": "CVE-2026-23279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23279"
},
{
"name": "CVE-2026-43216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43216"
},
{
"name": "CVE-2025-21795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21795"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2026-46122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46122"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2026-46022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46022"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21645"
},
{
"name": "CVE-2026-31422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31422"
},
{
"name": "CVE-2026-23359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23359"
},
{
"name": "CVE-2026-31533",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31533"
},
{
"name": "CVE-2026-46323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46323"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2025-21758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21758"
},
{
"name": "CVE-2026-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53219"
},
{
"name": "CVE-2026-31449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31449"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2026-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46120"
},
{
"name": "CVE-2026-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53249"
},
{
"name": "CVE-2026-31418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31418"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21706"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2026-23296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23296"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2026-46128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46128"
},
{
"name": "CVE-2026-31427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31427"
},
{
"name": "CVE-2026-31555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31555"
},
{
"name": "CVE-2024-57917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57917"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-31580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31580"
},
{
"name": "CVE-2026-43099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43099"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2026-31515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31515"
},
{
"name": "CVE-2026-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2026-64371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64371"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2026-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53236"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2024-58079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58079"
},
{
"name": "CVE-2025-71267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71267"
},
{
"name": "CVE-2026-46243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46243"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2026-22994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22994"
},
{
"name": "CVE-2026-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"name": "CVE-2025-22056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22056"
},
{
"name": "CVE-2026-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53362"
},
{
"name": "CVE-2025-61984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61984"
},
{
"name": "CVE-2026-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53168"
},
{
"name": "CVE-2026-23396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23396"
},
{
"name": "CVE-2025-37964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37964"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2026-31423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31423"
},
{
"name": "CVE-2026-46180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46180"
},
{
"name": "CVE-2026-46038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46038"
},
{
"name": "CVE-2026-31625",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31625"
},
{
"name": "CVE-2026-23370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23370"
},
{
"name": "CVE-2026-23302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23302"
},
{
"name": "CVE-2024-58086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58086"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2026-23414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23414"
},
{
"name": "CVE-2024-56631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56631"
},
{
"name": "CVE-2026-23315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23315"
},
{
"name": "CVE-2026-63357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63357"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2026-31669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31669"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-31671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31671"
},
{
"name": "CVE-2026-46234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46234"
},
{
"name": "CVE-2026-43024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43024"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-38322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38322"
},
{
"name": "CVE-2026-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53167"
},
{
"name": "CVE-2026-31694",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31694"
},
{
"name": "CVE-2026-23352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23352"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2026-46321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46321"
},
{
"name": "CVE-2026-31699",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31699"
},
{
"name": "CVE-2024-53166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53166"
},
{
"name": "CVE-2026-23367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23367"
},
{
"name": "CVE-2026-31628",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31628"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2024-27056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27056"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-31768",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31768"
},
{
"name": "CVE-2026-43026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43026"
},
{
"name": "CVE-2026-45997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45997"
},
{
"name": "CVE-2026-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53177"
},
{
"name": "CVE-2026-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53208"
},
{
"name": "CVE-2026-53255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53255"
},
{
"name": "CVE-2026-46070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46070"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2026-102076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102076"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2026-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"name": "CVE-2026-102073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102073"
},
{
"name": "CVE-2026-23255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23255"
},
{
"name": "CVE-2026-23446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23446"
},
{
"name": "CVE-2026-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53245"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2026-43035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43035"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2026-46172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46172"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2024-58068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58068"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2026-31665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31665"
},
{
"name": "CVE-2026-46161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46161"
},
{
"name": "CVE-2026-46026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46026"
},
{
"name": "CVE-2026-23300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23300"
},
{
"name": "CVE-2026-23444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23444"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2026-31391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31391"
},
{
"name": "CVE-2026-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53148"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2026-45844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45844"
},
{
"name": "CVE-2026-46110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46110"
},
{
"name": "CVE-2026-52946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52946"
},
{
"name": "CVE-2026-43501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43501"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2026-23243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23243"
},
{
"name": "CVE-2026-31521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31521"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2026-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53263"
},
{
"name": "CVE-2026-31634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31634"
},
{
"name": "CVE-2026-46018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46018"
},
{
"name": "CVE-2025-22060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22060"
},
{
"name": "CVE-2024-47736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47736"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-28956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28956"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2026-53012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53012"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2026-45991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45991"
},
{
"name": "CVE-2025-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37972"
},
{
"name": "CVE-2026-23379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23379"
},
{
"name": "CVE-2026-53356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53356"
},
{
"name": "CVE-2024-46786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46786"
},
{
"name": "CVE-2026-31421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31421"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2026-23381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23381"
},
{
"name": "CVE-2026-31518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31518"
},
{
"name": "CVE-2026-31712",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31712"
},
{
"name": "CVE-2026-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2026-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-23245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23245"
},
{
"name": "CVE-2026-46294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46294"
},
{
"name": "CVE-2026-46125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46125"
},
{
"name": "CVE-2024-49998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49998"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2026-31403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31403"
},
{
"name": "CVE-2024-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53170"
},
{
"name": "CVE-2026-43094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43094"
},
{
"name": "CVE-2026-53242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53242"
},
{
"name": "CVE-2026-64545",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64545"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2026-31504",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31504"
},
{
"name": "CVE-2026-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52910"
},
{
"name": "CVE-2026-23364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23364"
},
{
"name": "CVE-2026-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2026-23242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23242"
},
{
"name": "CVE-2026-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-46191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46191"
},
{
"name": "CVE-2024-54458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54458"
},
{
"name": "CVE-2026-53337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53337"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-31637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31637"
},
{
"name": "CVE-2025-39964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39964"
},
{
"name": "CVE-2026-31612",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31612"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2026-23274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23274"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2026-31417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31417"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2026-43111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43111"
},
{
"name": "CVE-2026-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2026-64423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64423"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2025-21844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21844"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-21676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21676"
},
{
"name": "CVE-2026-85115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-85115"
},
{
"name": "CVE-2026-53080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53080"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2026-43040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43040"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2026-23284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23284"
},
{
"name": "CVE-2026-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53221"
},
{
"name": "CVE-2026-52998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52998"
},
{
"name": "CVE-2026-31488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31488"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2026-23278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23278"
},
{
"name": "CVE-2026-31532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31532"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2026-53001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53001"
},
{
"name": "CVE-2026-23397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23397"
},
{
"name": "CVE-2025-21705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21705"
},
{
"name": "CVE-2026-23452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23452"
},
{
"name": "CVE-2026-23474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23474"
},
{
"name": "CVE-2025-40300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40300"
},
{
"name": "CVE-2026-53295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53295"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-23343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23343"
},
{
"name": "CVE-2026-53269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53269"
},
{
"name": "CVE-2026-23336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23336"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2026-46015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46015"
},
{
"name": "CVE-2026-46136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46136"
},
{
"name": "CVE-2026-31682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31682"
},
{
"name": "CVE-2026-46056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46056"
},
{
"name": "CVE-2026-23292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23292"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"name": "CVE-2026-31451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31451"
},
{
"name": "CVE-2026-23277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23277"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2026-31709",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31709"
},
{
"name": "CVE-2026-53253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53253"
},
{
"name": "CVE-2026-31441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31441"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2026-52948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52948"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2026-46086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46086"
},
{
"name": "CVE-2026-64412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64412"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-23455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23455"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2026-63355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63355"
},
{
"name": "CVE-2026-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53134"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2026-23335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23335"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
},
{
"name": "CVE-2026-31495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31495"
},
{
"name": "CVE-2026-46132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46132"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21865"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2026-46177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46177"
},
{
"name": "CVE-2026-43110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43110"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2026-53256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53256"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2026-31507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31507"
},
{
"name": "CVE-2026-64411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64411"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2026-23389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23389"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2026-46333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46333"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2026-31411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31411"
},
{
"name": "CVE-2026-31428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31428"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2026-43303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43303"
},
{
"name": "CVE-2026-23388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23388"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2026-23449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23449"
},
{
"name": "CVE-2026-46306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
},
{
"name": "CVE-2026-102074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102074"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-21648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21648"
},
{
"name": "CVE-2025-71266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71266"
},
{
"name": "CVE-2026-43089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43089"
},
{
"name": "CVE-2026-46021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46021"
},
{
"name": "CVE-2026-31676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31676"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"name": "CVE-2026-23442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23442"
},
{
"name": "CVE-2025-21724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21724"
},
{
"name": "CVE-2026-46107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46107"
},
{
"name": "CVE-2026-46047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46047"
},
{
"name": "CVE-2026-23458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23458"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2026-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"name": "CVE-2026-31649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31649"
},
{
"name": "CVE-2026-31674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31674"
},
{
"name": "CVE-2026-23310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23310"
},
{
"name": "CVE-2026-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53198"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2026-43027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43027"
},
{
"name": "CVE-2026-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2025-71123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71123"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2026-46163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46163"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-53264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53264"
},
{
"name": "CVE-2026-23339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23339"
},
{
"name": "CVE-2026-23010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23010"
},
{
"name": "CVE-2026-23272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23272"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2026-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53184"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2026-23321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23321"
},
{
"name": "CVE-2026-43114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43114"
},
{
"name": "CVE-2026-46187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46187"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2026-46168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46168"
},
{
"name": "CVE-2026-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53325"
},
{
"name": "CVE-2026-23395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23395"
},
{
"name": "CVE-2026-31708",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31708"
},
{
"name": "CVE-2026-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2026-64560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64560"
},
{
"name": "CVE-2026-85114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-85114"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2026-31503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31503"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-63353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63353"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"name": "CVE-2026-46003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46003"
},
{
"name": "CVE-2026-53358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53358"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2026-23378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23378"
},
{
"name": "CVE-2026-53352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53352"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2026-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53254"
},
{
"name": "CVE-2025-38736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38736"
},
{
"name": "CVE-2026-52928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52928"
},
{
"name": "CVE-2026-23291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23291"
},
{
"name": "CVE-2026-46023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46023"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2026-46304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46304"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2023-51384",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51384"
},
{
"name": "CVE-2021-41617",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41617"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2026-23382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23382"
},
{
"name": "CVE-2026-64425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64425"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2026-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52930"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-21703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21703"
},
{
"name": "CVE-2026-31446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31446"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2026-46193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46193"
},
{
"name": "CVE-2026-53265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53265"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2026-46033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46033"
},
{
"name": "CVE-2026-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52923"
},
{
"name": "CVE-2026-31500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31500"
},
{
"name": "CVE-2026-45850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45850"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2026-45834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45834"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2026-31700",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31700"
},
{
"name": "CVE-2024-56647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56647"
},
{
"name": "CVE-2026-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2026-72895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72895"
},
{
"name": "CVE-2026-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52933"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2026-23312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23312"
},
{
"name": "CVE-2026-31508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31508"
},
{
"name": "CVE-2026-64422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64422"
},
{
"name": "CVE-2025-21700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21700"
},
{
"name": "CVE-2026-23365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23365"
},
{
"name": "CVE-2026-43116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43116"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2026-31424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31424"
},
{
"name": "CVE-2026-23356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23356"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2026-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"name": "CVE-2025-21790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21790"
},
{
"name": "CVE-2025-40022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40022"
},
{
"name": "CVE-2023-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53292"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2026-46165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46165"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-31407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31407"
},
{
"name": "CVE-2026-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2025-21756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21756"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"name": "CVE-2026-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
},
{
"name": "CVE-2026-46322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46322"
},
{
"name": "CVE-2025-21716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21716"
},
{
"name": "CVE-2026-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"name": "CVE-2026-46088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46088"
},
{
"name": "CVE-2026-102075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102075"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2026-31629",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31629"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2026-46102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46102"
},
{
"name": "CVE-2026-64317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64317"
},
{
"name": "CVE-2026-23351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23351"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-10-13T00:00:00",
"last_revision_date": "2026-10-13T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1298",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-10-13T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"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 les produits Siemens. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits Siemens",
"vendor_advisories": [
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-832641",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-832641.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens ssb-091449",
"url": "https://cert-portal.siemens.com/productcert/html/ssb-091449.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-591731",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-591731.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-784472",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-333035",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-333035.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-550198",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-550198.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-159454",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-159454.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-457936",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-390352",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-390352.html"
}
]
}
FKIE_CVE-2025-37785
Vulnerability from fkie_nvd - Published: 2025-04-18 07:15 - Updated: 2026-10-15 02:177.1 (High) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/ext4/dir.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "14da7dbecb430e35b5889da8dae7bef33173b351",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "e47f472a664d70a3d104a6c2a035cdff55a719b4",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "b7531a4f99c3887439d778afaf418d1a01a5f01b",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "89503e5eae64637d0fa2218912b54660effe7d93",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "52a5509ab19a5d3afe301165d9b5787bba34d842",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "b47584c556444cf7acb66b26a62cbc348eb92b78",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "ac28c5684c1cdab650a7e5065b19e91577d37a4b",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "53bc45da8d8da92ec07877f5922b130562eb4b00",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
},
{
"lessThan": "d5e206778e96e8667d3bde695ad372c296dc9353",
"status": "affected",
"version": "ac27a0ec112a089f1a5102bc8dffc79c8c815571",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/ext4/dir.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.19"
},
{
"lessThan": "2.6.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.293",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.236",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.180",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.134",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.87",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.6",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "V3.1.7",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5093EDFD-21CC-4898-9E34-0C31FADEF44A",
"versionEndExcluding": "5.10.236",
"versionStartIncluding": "2.6.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D19801C8-3D18-405D-9989-E6C9B30255FA",
"versionEndExcluding": "5.15.180",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "3985DEC3-0437-4177-BC42-314AB575285A",
"versionEndExcluding": "6.1.134",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "EFF24260-49B1-4251-9477-C564CFDAD25B",
"versionEndExcluding": "6.6.87",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "26CAB76D-F00F-43CE-BEAD-7097F8FB1D6C",
"versionEndExcluding": "6.12.23",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E7E864B0-8C00-4679-BA55-659B4C9C3AD3",
"versionEndExcluding": "6.13.11",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "FADAE5D8-4808-442C-B218-77B2CE8780A0",
"versionEndExcluding": "6.14.2",
"versionStartIncluding": "6.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0027.\u0027 dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0027.\u0027\nand \u0027..\u0027 as directory entries in the first data block. It first loads\nthe \u0027.\u0027 dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0027..\u0027 dir\nentry (in ext4_next_entry). It assumes the \u0027..\u0027 dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0027.\u0027 is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \"struct ext4_dir_entry_2 *de\" point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0027.\u0027 dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u003cTASK\u003e\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: correcci\u00f3n de lectura OOB al comprobar el directorio dotdot Montar un sistema de archivos da\u00f1ado con un directorio que contiene una entrada de directorio \u0027.\u0027 con rec_len == tama\u00f1o de bloque da como resultado una lectura fuera de los l\u00edmites (m\u00e1s adelante, cuando se elimina el directorio da\u00f1ado). ext4_empty_dir() asume que cada directorio ext4 contiene al menos \u0027.\u0027 y \u0027..\u0027 como entradas de directorio en el primer bloque de datos. Primero carga la entrada de directorio \u0027.\u0027, realiza comprobaciones de cordura llamando a ext4_check_dir_entry() y luego usa su miembro rec_len para calcular la ubicaci\u00f3n de la entrada de directorio \u0027..\u0027 (en ext4_next_entry). Asume que la entrada de directorio \u0027..\u0027 encaja en el mismo bloque de datos. Si el rec_len de \u0027.\u0027 Si es exactamente un bloque (4 KB), no cumple con las comprobaciones de seguridad (se considera la \u00faltima entrada de directorio del bloque de datos) y deja el puntero \"struct ext4_dir_entry_2 *de\" justo despu\u00e9s de la ranura de memoria asignada al bloque de datos. La siguiente llamada a ext4_check_dir_entry() con el nuevo valor de de desreferencia este puntero, lo que resulta en un acceso a la memoria fuera de los l\u00edmites. Para solucionar esto, extienda __ext4_check_dir_entry() para verificar las entradas de directorio \".\" que llegan al final del bloque de datos. Aseg\u00farese de ignorar las entradas de directorio falsas para la suma de comprobaci\u00f3n (verificando name_len para ver si es distinto de cero). Nota: KASAN informa que esto es un use-after-free en caso de que otra estructura se haya liberado recientemente de la ranura m\u00e1s all\u00e1 del l\u00edmite, pero en realidad es una lectura fuera de banda (OOB). Este problema fue detectado por la herramienta syzkaller. Rastreo de llamadas: [38.594108] ERROR: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e"
}
],
"id": "CVE-2025-37785",
"lastModified": "2026-10-15T02:17:48.740",
"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"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-04-18T07:15:42.693",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-W7JC-WQPW-QXQQ
Vulnerability from github – Published: 2025-04-18 15:31 – Updated: 2026-10-15 03:34In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e
{
"affected": [],
"aliases": [
"CVE-2025-37785"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-18T07:15:42Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0027.\u0027 dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0027.\u0027\nand \u0027..\u0027 as directory entries in the first data block. It first loads\nthe \u0027.\u0027 dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0027..\u0027 dir\nentry (in ext4_next_entry). It assumes the \u0027..\u0027 dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0027.\u0027 is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \"struct ext4_dir_entry_2 *de\" point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0027.\u0027 dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u003cTASK\u003e\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e",
"id": "GHSA-w7jc-wqpw-qxqq",
"modified": "2026-10-15T03:34:49Z",
"published": "2025-04-18T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-26-209-04
Vulnerability from csaf_cisa - Published: 2026-07-14 00:00 - Updated: 2026-07-28 06:00In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e
ICSA-26-295-11
Vulnerability from csaf_cisa - Published: 2026-10-13 00:00 - Updated: 2026-10-22 06:00In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e
MSRC_CVE-2025-37785
Vulnerability from csaf_microsoft - Published: 2025-04-02 00:00 - Updated: 2026-02-21 04:14OESA-2025-1465 (CVE-2020-36789)
Vulnerability from osv_openeuler – Published: 2025-05-09 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context
If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but not always, the case), the 'WARN_ON(in_irq)' in net/core/skbuff.c#skb_release_head_state() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference.
The root cause of this issue is the call to kfree_skb() instead of dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().
This patch prevents the skb to be freed within the call to netif_rx() by incrementing its reference count with skb_get(). The skb is finally freed by one of the in-irq-context safe functions: dev_consume_skb_any() or dev_kfree_skb_any(). The "any" version is used because some drivers might call can_get_echo_skb() in a normal context.
The reason for this issue to occur is that initially, in the core network stack, loopback skb were not supposed to be received in hardware IRQ context. The CAN stack is an exeption.
This bug was previously reported back in 2017 in [1] but the proposed patch never got accepted.
While [1] directly modifies net/core/dev.c, we try to propose here a smoother modification local to CAN network stack (the assumption behind is that only CAN devices are affected by this issue).
[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com(CVE-2020-36789)
In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: cirrusfb: check pixclock to avoid divide by zero
Do a sanity check on pixclock value to avoid divide by zero.
If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible.
Syzkaller reported a divide error in cirrusfb_check_pixclock.
divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260
Call Trace: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47641)
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_restart: fix use after free bug
After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the netif_rx_ni() in: stats->rx_bytes += cf->len;
Reordering the lines solves the issue.(CVE-2021-47668)
In the Linux kernel, the following vulnerability has been resolved:
can: peak_usb: fix use after free bugs
After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the peak_usb_netif_rx_ni().
Reordering the lines solves the issue.(CVE-2021-47670)
In the Linux kernel, the following vulnerability has been resolved:
qede: confirm skb is allocated before using
qede_build_skb() assumes build_skb() always works and goes straight to skb_reserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL.
Add a check in case build_skb() failed to allocate and return NULL.
The NULL return is handled correctly in callers to qede_build_skb().(CVE-2022-49084)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix leak of nested actions
While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions.
Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory.
For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc():
actions:clone(ct(commit),0)
Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references.
Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS.
Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively.
New build time assertion should protect us from this problem if new actions will be added in the future.
Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too.(CVE-2022-49086)
In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix abort all task initialization
In pm80xx_send_abort_all(), the n_elem field of the ccb used is not initialized to 0. This missing initialization sometimes lead to the task completion path seeing the ccb with a non-zero n_elem resulting in the execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(), causing a crash such as:
[ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Call Trace: [ 197.765127] <IRQ> [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx] [ 197.772364] ? do_raw_spin_unlock+0x54/0x220 [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx] [ 197.782406] process_oq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lock_acquire+0x194/0x490 [ 197.790697] ? handle_irq_event+0x10e/0x1b0 [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx] [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0 [ 197.818785] __do_softirq+0x1b5/0x82d [ 197.822485] ? do_raw_spin_unlock+0x54/0x220 [ 197.826799] __irq_exit_rcu+0x17e/0x1e0 [ 197.830678] irq_exit_rcu+0xa/0x20 [ 197.834114] common_interrupt+0x78/0x90 [ 197.840051] </IRQ> [ 197.844236] <TASK> [ 197.848397] asm_common_interrupt+0x1e/0x40
Avoid this issue by always initializing the ccb n_elem field to 0 in pm8001_send_abort_all(), pm8001_send_read_log() and pm80xx_send_abort_all().(CVE-2022-49217)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()
In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode().
Fix this by adding a NULL check of mode.
This bug was found by a static analyzer.
Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code.(CVE-2022-49232)
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8712: fix uninit-value in r871xu_drv_init()
When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized.
BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30
Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8(CVE-2022-49298)
In the Linux kernel, the following vulnerability has been resolved:
driver: base: fix UAF when driver_attach failed
When driver_attach(drv); failed, the driver_private will be freed. But it has been added to the bus, which caused a UAF.
To fix it, we need to delete it from the bus when failed.(CVE-2022-49385)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hfi1: Prevent panic when SDMA is disabled
If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is:
sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64
The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.(CVE-2022-49429)
In the Linux kernel, the following vulnerability has been resolved:
sfc: fix use after free when disabling sriov
Use after free is detected by kfence when disabling sriov. What was read after being freed was vf->pci_dev: it was freed from pci_disable_sriov and later read in efx_ef10_sriov_free_vf_vports, called from efx_ef10_sriov_free_vf_vswitching.
Set the pointer to NULL at release time to not trying to read it later.
Reproducer and dmesg log (note that kfence doesn't detect it every time): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs
BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]
Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k
allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2022-49626)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: Use separate src/dst nodes when preloading css_sets for migration
Each cset (css_set) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mg_preload_node on either the mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time.
Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1:
#1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs
the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one.
After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens:
-
cgroup_migrate_add_src() is called on B for the leader.
-
cgroup_migrate_add_src() is called on A for the other threads.
-
cgroup_migrate_prepare_dst() is called. It scans the src list.
-
It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy.
-
and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly.
-
The rest of migration takes place with B on the src list but nothing on the dst list.
This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free.
This is caused by overloading cset->mg_preload_node for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too.
This patch fixes the issue by separating out cset->mg_preload_node into ->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst preloadings don't interfere with each other.(CVE-2022-49647)
In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: fix ->anon_vma race
If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked.
Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains).
If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them.
Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access.
Hitting this bug causes a lockdep warning in collapse_and_free_pmd(), in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access.(CVE-2023-52935)
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: validate parameter addr in mdiobus_get_phy()
The caller may pass any value as addr, what may result in an out-of-bounds access to array mdio_map. One existing case is stmmac_init_phy() that may pass -1 as addr. Therefore validate addr before using it.(CVE-2023-53019)
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: Fix use-after-free in local_cleanup()
Fix a use-after-free that occurs in kfree_skb() called from local_cleanup(). This could happen when killing nfc daemon (e.g. neard) after detaching an nfc device. When detaching an nfc device, local_cleanup() called from nfc_llcp_unregister_device() frees local->rx_pending and decreases local->ref by kref_put() in nfc_llcp_local_put(). In the terminating process, nfc daemon releases all sockets and it leads to decreasing local->ref. After the last release of local->ref, local_cleanup() called from local_release() frees local->rx_pending again, which leads to the bug.
Setting local->rx_pending to NULL in local_cleanup() could prevent use-after-free when local_cleanup() is called twice.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in kfree_skb()
Call Trace: dump_stack_lvl (lib/dump_stack.c:106) print_address_description.constprop.0.cold (mm/kasan/report.c:306) kasan_check_range (mm/kasan/generic.c:189) kfree_skb (net/core/skbuff.c:955) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172) nfc_llcp_local_put (net/nfc/llcp_core.c:181) llcp_sock_destruct (net/nfc/llcp_sock.c:959) __sk_destruct (net/core/sock.c:2133) sk_destruct (net/core/sock.c:2181) __sk_free (net/core/sock.c:2192) sk_free (net/core/sock.c:2203) llcp_sock_release (net/nfc/llcp_sock.c:646) __sock_release (net/socket.c:650) sock_close (net/socket.c:1365) __fput (fs/file_table.c:306) task_work_run (kernel/task_work.c:179) ptrace_notify (kernel/signal.c:2354) syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278) syscall_exit_to_user_mode (kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:86) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)
Allocated by task 4719: kasan_save_stack (mm/kasan/common.c:45) __kasan_slab_alloc (mm/kasan/common.c:325) slab_post_alloc_hook (mm/slab.h:766) kmem_cache_alloc_node (mm/slub.c:3497) __alloc_skb (net/core/skbuff.c:552) pn533_recv_response (drivers/nfc/pn533/usb.c:65) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671) usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704) tasklet_action_common.isra.0 (kernel/softirq.c:797) __do_softirq (kernel/softirq.c:571)
Freed by task 1901: kasan_save_stack (mm/kasan/common.c:45) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/genericdd.c:518) __kasan_slab_free (mm/kasan/common.c:236) kmem_cache_free (mm/slub.c:3809) kfree_skbmem (net/core/skbuff.c:874) kfree_skb (net/core/skbuff.c:931) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617) nfc_unregister_device (net/nfc/core.c:1179) pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846) pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579) usb_unbind_interface (drivers/usb/core/driver.c:458) device_release_driver_internal (drivers/base/dd.c:1279) bus_remove_device (drivers/base/bus.c:529) device_del (drivers/base/core.c:3665) usb_disable_device (drivers/usb/core/message.c:1420) usb_disconnect (drivers/usb/core.c:2261) hub_event (drivers/usb/core/hub.c:5833) process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281) worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423) kthread (kernel/kthread.c:319) ret_from_fork (arch/x86/entry/entry_64.S:301)(CVE-2023-53023)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.
When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of an arithmetic expression 2 << (netmask - mask_bits - 1) is subject to overflow due to a failure casting operands to a larger data type before performing the arithmetic.
Note that it's harmless since the value will be checked at the next step.
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53032)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add check read-only before truncation in jfs_truncate_nolock()
Added a check for "read-only" mode in the jfs_truncate_nolock
function to avoid errors related to writing to a read-only
filesystem.
Call stack:
block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL)
If the isReadOnly(ip) condition is triggered in
jfs_truncate_nolock, the function execution will stop, and no
further data modification will occur. Instead, the xtTruncate
function will be called with the "COMMIT_WMAP" flag, preventing
modifications in "read-only" mode.(CVE-2024-58094)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: extend RCU protection in igmp6_send()
igmp6_send() can be called without RTNL or RCU being held.
Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF.
Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.
Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection.(CVE-2025-21759)
In the Linux kernel, the following vulnerability has been resolved:
ndisc: extend RCU protection in ndisc_send_skb()
ndisc_send_skb() can be called without RTNL or RCU held.
Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF.(CVE-2025-21760)
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: use RCU protection in ovs_vport_cmd_fill_info()
ovs_vport_cmd_fill_info() can be called without RTNL or RCU.
Use RCU protection and dev_net_rcu() to avoid potential UAF.(CVE-2025-21761)
In the Linux kernel, the following vulnerability has been resolved:
arp: use RCU protection in arp_xmit()
arp_xmit() can be called without RTNL or RCU protection.
Use RCU protection to avoid potential UAF.(CVE-2025-21762)
In the Linux kernel, the following vulnerability has been resolved:
neighbour: use RCU protection in __neigh_notify()
__neigh_notify() can be called without RTNL or RCU protection.
Use RCU protection to avoid potential UAF.(CVE-2025-21763)
In the Linux kernel, the following vulnerability has been resolved:
ndisc: use RCU protection in ndisc_alloc_skb()
ndisc_alloc_skb() can be called without RTNL or RCU being held.
Add RCU protection to avoid possible UAF.(CVE-2025-21764)
In the Linux kernel, the following vulnerability has been resolved:
iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()
When performing an iSCSI boot using IPv6, iscsistart still reads the /sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix length is 64, this causes the shift exponent to become negative, triggering a UBSAN warning. As the concept of a subnet mask does not apply to IPv6, the value is set to ~0 to suppress the warning message.(CVE-2025-21993)
In the Linux kernel, the following vulnerability has been resolved:
net: atm: fix use after free in lec_send()
The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free.(CVE-2025-22004)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free in print_graph_function_flags during tracer switching
Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script:
$ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer
The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show():
- One through 'iter->trace->print_line()';
- Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.
Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags.
Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'.
To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers.
[1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/(CVE-2025-22035)
In the Linux kernel, the following vulnerability has been resolved:
net: fix geneve_opt length integer overflow
struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes.
However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to fake a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read.
One example crash log is like below:
[ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8
Fix these issues by enforing correct length condition in related policies.(CVE-2025-22055)
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix memory accounting leak.
Matt Dowling reported a weird UDP memory usage issue.
Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.
We can reproduce the issue with the script below [0]:
-
/proc/net/sockstat reports 0 pages
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 0
-
Run the script till the report reaches 524,288
python3 test.py & sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT
-
Kill the socket and confirm the number never drops
pkill python3 && sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 524288
-
(necessary since v6.0) Trigger proto_memory_pcpu_drain()
python3 test.py & sleep 1 && pkill python3
-
The number doubles
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 1048577
The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release().
When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.
The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.
Then, the released amount is calculated as follows:
1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().
When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().
At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4).
Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.
This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops.
To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta.
Note that first_packet_length() also potentially has the same problem.
[0]: from socket import *
SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1
s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)
c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname())
data = b'a' * 100
while True: c.send(data)(CVE-2025-22058)
In the Linux kernel, the following vulnerability has been resolved:
md/raid1,raid10: don't ignore IO flags
If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced.
Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks.
Fix those problems by keep IO flags from master bio.
Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")(CVE-2025-22125)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2505.1.0.0326.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2505.1.0.0326.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2505.1.0.0326.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context\n\nIf a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but\nnot always, the case), the \u0026apos;WARN_ON(in_irq)\u0026apos; in\nnet/core/skbuff.c#skb_release_head_state() might be triggered, under network\ncongestion circumstances, together with the potential risk of a NULL pointer\ndereference.\n\nThe root cause of this issue is the call to kfree_skb() instead of\ndev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().\n\nThis patch prevents the skb to be freed within the call to netif_rx() by\nincrementing its reference count with skb_get(). The skb is finally freed by\none of the in-irq-context safe functions: dev_consume_skb_any() or\ndev_kfree_skb_any(). The \u0026quot;any\u0026quot; version is used because some drivers might call\ncan_get_echo_skb() in a normal context.\n\nThe reason for this issue to occur is that initially, in the core network\nstack, loopback skb were not supposed to be received in hardware IRQ context.\nThe CAN stack is an exeption.\n\nThis bug was previously reported back in 2017 in [1] but the proposed patch\nnever got accepted.\n\nWhile [1] directly modifies net/core/dev.c, we try to propose here a\nsmoother modification local to CAN network stack (the assumption\nbehind is that only CAN devices are affected by this issue).\n\n[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com(CVE-2020-36789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvideo: fbdev: cirrusfb: check pixclock to avoid divide by zero\n\nDo a sanity check on pixclock value to avoid divide by zero.\n\nIf the pixclock value is zero, the cirrusfb driver will round up\npixclock to get the derived frequency as close to maxclock as\npossible.\n\nSyzkaller reported a divide error in cirrusfb_check_pixclock.\n\ndivide error: 0000 [#1] SMP KASAN PTI\nCPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2\nRIP: 0010:cirrusfb_check_var+0x6f1/0x1260\n\nCall Trace:\n fb_set_var+0x398/0xf90\n do_fb_ioctl+0x4b8/0x6f0\n fb_ioctl+0xeb/0x130\n __x64_sys_ioctl+0x19d/0x220\n do_syscall_64+0x3a/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47641)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: can_restart: fix use after free bug\n\nAfter calling netif_rx_ni(skb), dereferencing skb is unsafe.\nEspecially, the can_frame cf which aliases skb memory is accessed\nafter the netif_rx_ni() in:\n stats-\u0026gt;rx_bytes += cf-\u0026gt;len;\n\nReordering the lines solves the issue.(CVE-2021-47668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: peak_usb: fix use after free bugs\n\nAfter calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe.\nEspecially, the can_frame cf which aliases skb memory is accessed\nafter the peak_usb_netif_rx_ni().\n\nReordering the lines solves the issue.(CVE-2021-47670)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqede: confirm skb is allocated before using\n\nqede_build_skb() assumes build_skb() always works and goes straight\nto skb_reserve(). However, build_skb() can fail under memory pressure.\nThis results in a kernel panic because the skb to reserve is NULL.\n\nAdd a check in case build_skb() failed to allocate and return NULL.\n\nThe NULL return is handled correctly in callers to qede_build_skb().(CVE-2022-49084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix leak of nested actions\n\nWhile parsing user-provided actions, openvswitch module may dynamically\nallocate memory and store pointers in the internal copy of the actions.\nSo this memory has to be freed while destroying the actions.\n\nCurrently there are only two such actions: ct() and set(). However,\nthere are many actions that can hold nested lists of actions and\novs_nla_free_flow_actions() just jumps over them leaking the memory.\n\nFor example, removal of the flow with the following actions will lead\nto a leak of the memory allocated by nf_ct_tmpl_alloc():\n\n actions:clone(ct(commit),0)\n\nNon-freed set() action may also leak the \u0026apos;dst\u0026apos; structure for the\ntunnel info including device references.\n\nUnder certain conditions with a high rate of flow rotation that may\ncause significant memory leak problem (2MB per second in reporter\u0026apos;s\ncase). The problem is also hard to mitigate, because the user doesn\u0026apos;t\nhave direct control over the datapath flows generated by OVS.\n\nFix that by iterating over all the nested actions and freeing\neverything that needs to be freed recursively.\n\nNew build time assertion should protect us from this problem if new\nactions will be added in the future.\n\nUnfortunately, openvswitch module doesn\u0026apos;t use NLA_F_NESTED, so all\nattributes has to be explicitly checked. sample() and clone() actions\nare mixing extra attributes into the user-provided action list. That\nprevents some code generalization too.(CVE-2022-49086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: pm8001: Fix abort all task initialization\n\nIn pm80xx_send_abort_all(), the n_elem field of the ccb used is not\ninitialized to 0. This missing initialization sometimes lead to the task\ncompletion path seeing the ccb with a non-zero n_elem resulting in the\nexecution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),\ncausing a crash such as:\n\n[ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280\n[ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012\n[ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0\n[ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0\n[ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b\n[ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000\n[ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000\n[ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000\n[ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0\n[ 197.762656] Call Trace:\n[ 197.765127] \u0026lt;IRQ\u0026gt;\n[ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]\n[ 197.772364] ? do_raw_spin_unlock+0x54/0x220\n[ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]\n[ 197.782406] process_oq+0xe85/0x7890 [pm80xx]\n[ 197.786817] ? lock_acquire+0x194/0x490\n[ 197.790697] ? handle_irq_event+0x10e/0x1b0\n[ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]\n[ 197.800378] ? __wake_up_bit+0x100/0x100\n[ 197.804340] ? lock_is_held_type+0x98/0x110\n[ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx]\n[ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0\n[ 197.818785] __do_softirq+0x1b5/0x82d\n[ 197.822485] ? do_raw_spin_unlock+0x54/0x220\n[ 197.826799] __irq_exit_rcu+0x17e/0x1e0\n[ 197.830678] irq_exit_rcu+0xa/0x20\n[ 197.834114] common_interrupt+0x78/0x90\n[ 197.840051] \u0026lt;/IRQ\u0026gt;\n[ 197.844236] \u0026lt;TASK\u0026gt;\n[ 197.848397] asm_common_interrupt+0x1e/0x40\n\nAvoid this issue by always initializing the ccb n_elem field to 0 in\npm8001_send_abort_all(), pm8001_send_read_log() and\npm80xx_send_abort_all().(CVE-2022-49217)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()\n\nIn amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()\nis assigned to mode and is passed to drm_mode_probed_add() directly after\nthat. drm_mode_probed_add() passes \u0026amp;mode-\u0026gt;head to list_add_tail(), and\nthere is a dereference of it in list_add_tail() without recoveries, which\ncould lead to NULL pointer dereference on failure of\namdgpu_dm_create_common_mode().\n\nFix this by adding a NULL check of mode.\n\nThis bug was found by a static analyzer.\n\nBuilds with \u0026apos;make allyesconfig\u0026apos; show no new warnings,\nand our static analyzer no longer warns about this code.(CVE-2022-49232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8712: fix uninit-value in r871xu_drv_init()\n\nWhen \u0026apos;tmpU1b\u0026apos; returns from r8712_read8(padapter, EE_9346CR) is 0,\n\u0026apos;mac[6]\u0026apos; will not be initialized.\n\nBUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541\n r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541\n usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396\n really_probe+0x653/0x14b0 drivers/base/dd.c:596\n __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752\n driver_probe_device drivers/base/dd.c:782 [inline]\n __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899\n bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427\n __device_attach+0x593/0x8e0 drivers/base/dd.c:970\n device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017\n bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487\n device_add+0x1fff/0x26e0 drivers/base/core.c:3405\n usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170\n usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238\n usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293\n really_probe+0x653/0x14b0 drivers/base/dd.c:596\n __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752\n driver_probe_device drivers/base/dd.c:782 [inline]\n __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899\n bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427\n __device_attach+0x593/0x8e0 drivers/base/dd.c:970\n device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017\n bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487\n device_add+0x1fff/0x26e0 drivers/base/core.c:3405\n usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566\n hub_port_connect drivers/usb/core/hub.c:5358 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5502 [inline]\n port_event drivers/usb/core/hub.c:5660 [inline]\n hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742\n process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307\n worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454\n kthread+0x3c7/0x500 kernel/kthread.c:377\n ret_from_fork+0x1f/0x30\n\nLocal variable mac created at:\n r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394\n usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396\n\nKMSAN: uninit-value in r871xu_drv_init\nhttps://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8(CVE-2022-49298)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver: base: fix UAF when driver_attach failed\n\nWhen driver_attach(drv); failed, the driver_private will be freed.\nBut it has been added to the bus, which caused a UAF.\n\nTo fix it, we need to delete it from the bus when failed.(CVE-2022-49385)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Prevent panic when SDMA is disabled\n\nIf the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to\nhfi1_write_iter() will dereference a NULL pointer and panic. A typical\nstack frame is:\n\n sdma_select_user_engine [hfi1]\n hfi1_user_sdma_process_request [hfi1]\n hfi1_write_iter [hfi1]\n do_iter_readv_writev\n do_iter_write\n vfs_writev\n do_writev\n do_syscall_64\n\nThe fix is to test for SDMA in hfi1_write_iter() and fail the I/O with\nEINVAL.(CVE-2022-49429)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix use after free when disabling sriov\n\nUse after free is detected by kfence when disabling sriov. What was read\nafter being freed was vf-\u0026gt;pci_dev: it was freed from pci_disable_sriov\nand later read in efx_ef10_sriov_free_vf_vports, called from\nefx_ef10_sriov_free_vf_vswitching.\n\nSet the pointer to NULL at release time to not trying to read it later.\n\nReproducer and dmesg log (note that kfence doesn\u0026apos;t detect it every time):\n$ echo 1 \u0026gt; /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n$ echo 0 \u0026gt; /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n\n BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n\n Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224):\n efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n efx_ef10_pci_sriov_disable+0x38/0x70 [sfc]\n efx_pci_sriov_configure+0x24/0x40 [sfc]\n sriov_numvfs_store+0xfe/0x140\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x11f/0x1b0\n vfs_write+0x1eb/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k\n\n allocated by task 6771 on cpu 10 at 3137.860196s:\n pci_alloc_dev+0x21/0x60\n pci_iov_add_virtfn+0x2a2/0x320\n sriov_enable+0x212/0x3e0\n efx_ef10_sriov_configure+0x67/0x80 [sfc]\n efx_pci_sriov_configure+0x24/0x40 [sfc]\n sriov_numvfs_store+0xba/0x140\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x11f/0x1b0\n vfs_write+0x1eb/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n freed by task 6771 on cpu 12 at 3170.991309s:\n device_release+0x34/0x90\n kobject_cleanup+0x3a/0x130\n pci_iov_remove_virtfn+0xd9/0x120\n sriov_disable+0x30/0xe0\n efx_ef10_pci_sriov_disable+0x57/0x70 [sfc]\n efx_pci_sriov_configure+0x24/0x40 [sfc]\n sriov_numvfs_store+0xfe/0x140\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x11f/0x1b0\n vfs_write+0x1eb/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x5c/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2022-49626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: Use separate src/dst nodes when preloading css_sets for migration\n\nEach cset (css_set) is pinned by its tasks. When we\u0026apos;re moving tasks around\nacross csets for a migration, we need to hold the source and destination\ncsets to ensure that they don\u0026apos;t go away while we\u0026apos;re moving tasks about. This\nis done by linking cset-\u0026gt;mg_preload_node on either the\nmgctx-\u0026gt;preloaded_src_csets or mgctx-\u0026gt;preloaded_dst_csets list. Using the\nsame cset-\u0026gt;mg_preload_node for both the src and dst lists was deemed okay as\na cset can\u0026apos;t be both the source and destination at the same time.\n\nUnfortunately, this overloading becomes problematic when multiple tasks are\ninvolved in a migration and some of them are identity noop migrations while\nothers are actually moving across cgroups. For example, this can happen with\nthe following sequence on cgroup1:\n\n #1\u0026gt; mkdir -p /sys/fs/cgroup/misc/a/b\n #2\u0026gt; echo $$ \u0026gt; /sys/fs/cgroup/misc/a/cgroup.procs\n #3\u0026gt; RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS \u0026amp;\n #4\u0026gt; PID=$!\n #5\u0026gt; echo $PID \u0026gt; /sys/fs/cgroup/misc/a/b/tasks\n #6\u0026gt; echo $PID \u0026gt; /sys/fs/cgroup/misc/a/cgroup.procs\n\nthe process including the group leader back into a. In this final migration,\nnon-leader threads would be doing identity migration while the group leader\nis doing an actual one.\n\nAfter #3, let\u0026apos;s say the whole process was in cset A, and that after #4, the\nleader moves to cset B. Then, during #6, the following happens:\n\n 1. cgroup_migrate_add_src() is called on B for the leader.\n\n 2. cgroup_migrate_add_src() is called on A for the other threads.\n\n 3. cgroup_migrate_prepare_dst() is called. It scans the src list.\n\n 4. It notices that B wants to migrate to A, so it tries to A to the dst\n list but realizes that its -\u0026gt;mg_preload_node is already busy.\n\n 5. and then it notices A wants to migrate to A as it\u0026apos;s an identity\n migration, it culls it by list_del_init()\u0026apos;ing its -\u0026gt;mg_preload_node and\n putting references accordingly.\n\n 6. The rest of migration takes place with B on the src list but nothing on\n the dst list.\n\nThis means that A isn\u0026apos;t held while migration is in progress. If all tasks\nleave A before the migration finishes and the incoming task pins it, the\ncset will be destroyed leading to use-after-free.\n\nThis is caused by overloading cset-\u0026gt;mg_preload_node for both src and dst\npreload lists. We wanted to exclude the cset from the src list but ended up\ninadvertently excluding it from the dst list too.\n\nThis patch fixes the issue by separating out cset-\u0026gt;mg_preload_node into\n-\u0026gt;mg_src_preload_node and -\u0026gt;mg_dst_preload_node, so that the src and dst\npreloadings don\u0026apos;t interfere with each other.(CVE-2022-49647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/khugepaged: fix -\u0026gt;anon_vma race\n\nIf an -\u0026gt;anon_vma is attached to the VMA, collapse_and_free_pmd() requires\nit to be locked.\n\nPage table traversal is allowed under any one of the mmap lock, the\nanon_vma lock (if the VMA is associated with an anon_vma), and the\nmapping lock (if the VMA is associated with a mapping); and so to be\nable to remove page tables, we must hold all three of them. \nretract_page_tables() bails out if an -\u0026gt;anon_vma is attached, but does\nthis check before holding the mmap lock (as the comment above the check\nexplains).\n\nIf we racily merged an existing -\u0026gt;anon_vma (shared with a child\nprocess) from a neighboring VMA, subsequent rmap traversals on pages\nbelonging to the child will be able to see the page tables that we are\nconcurrently removing while assuming that nothing else can access them.\n\nRepeat the -\u0026gt;anon_vma check once we hold the mmap lock to ensure that\nthere really is no concurrent page table access.\n\nHitting this bug causes a lockdep warning in collapse_and_free_pmd(),\nin the line \u0026quot;lockdep_assert_held_write(\u0026amp;vma-\u0026gt;anon_vma-\u0026gt;root-\u0026gt;rwsem)\u0026quot;. \nIt can also lead to use-after-free access.(CVE-2023-52935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mdio: validate parameter addr in mdiobus_get_phy()\n\nThe caller may pass any value as addr, what may result in an out-of-bounds\naccess to array mdio_map. One existing case is stmmac_init_phy() that\nmay pass -1 as addr. Therefore validate addr before using it.(CVE-2023-53019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: Fix use-after-free in local_cleanup()\n\nFix a use-after-free that occurs in kfree_skb() called from\nlocal_cleanup(). This could happen when killing nfc daemon (e.g. neard)\nafter detaching an nfc device.\nWhen detaching an nfc device, local_cleanup() called from\nnfc_llcp_unregister_device() frees local-\u0026gt;rx_pending and decreases\nlocal-\u0026gt;ref by kref_put() in nfc_llcp_local_put().\nIn the terminating process, nfc daemon releases all sockets and it leads\nto decreasing local-\u0026gt;ref. After the last release of local-\u0026gt;ref,\nlocal_cleanup() called from local_release() frees local-\u0026gt;rx_pending\nagain, which leads to the bug.\n\nSetting local-\u0026gt;rx_pending to NULL in local_cleanup() could prevent\nuse-after-free when local_cleanup() is called twice.\n\nFound by a modified version of syzkaller.\n\nBUG: KASAN: use-after-free in kfree_skb()\n\nCall Trace:\ndump_stack_lvl (lib/dump_stack.c:106)\nprint_address_description.constprop.0.cold (mm/kasan/report.c:306)\nkasan_check_range (mm/kasan/generic.c:189)\nkfree_skb (net/core/skbuff.c:955)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)\nnfc_llcp_local_put (net/nfc/llcp_core.c:181)\nllcp_sock_destruct (net/nfc/llcp_sock.c:959)\n__sk_destruct (net/core/sock.c:2133)\nsk_destruct (net/core/sock.c:2181)\n__sk_free (net/core/sock.c:2192)\nsk_free (net/core/sock.c:2203)\nllcp_sock_release (net/nfc/llcp_sock.c:646)\n__sock_release (net/socket.c:650)\nsock_close (net/socket.c:1365)\n__fput (fs/file_table.c:306)\ntask_work_run (kernel/task_work.c:179)\nptrace_notify (kernel/signal.c:2354)\nsyscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)\nsyscall_exit_to_user_mode (kernel/entry/common.c:296)\ndo_syscall_64 (arch/x86/entry/common.c:86)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)\n\nAllocated by task 4719:\nkasan_save_stack (mm/kasan/common.c:45)\n__kasan_slab_alloc (mm/kasan/common.c:325)\nslab_post_alloc_hook (mm/slab.h:766)\nkmem_cache_alloc_node (mm/slub.c:3497)\n__alloc_skb (net/core/skbuff.c:552)\npn533_recv_response (drivers/nfc/pn533/usb.c:65)\n__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)\nusb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)\ntasklet_action_common.isra.0 (kernel/softirq.c:797)\n__do_softirq (kernel/softirq.c:571)\n\nFreed by task 1901:\nkasan_save_stack (mm/kasan/common.c:45)\nkasan_set_track (mm/kasan/common.c:52)\nkasan_save_free_info (mm/kasan/genericdd.c:518)\n__kasan_slab_free (mm/kasan/common.c:236)\nkmem_cache_free (mm/slub.c:3809)\nkfree_skbmem (net/core/skbuff.c:874)\nkfree_skb (net/core/skbuff.c:931)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)\nnfc_unregister_device (net/nfc/core.c:1179)\npn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)\npn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)\nusb_unbind_interface (drivers/usb/core/driver.c:458)\ndevice_release_driver_internal (drivers/base/dd.c:1279)\nbus_remove_device (drivers/base/bus.c:529)\ndevice_del (drivers/base/core.c:3665)\nusb_disable_device (drivers/usb/core/message.c:1420)\nusb_disconnect (drivers/usb/core.c:2261)\nhub_event (drivers/usb/core/hub.c:5833)\nprocess_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)\nworker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)\nkthread (kernel/kthread.c:319)\nret_from_fork (arch/x86/entry/entry_64.S:301)(CVE-2023-53023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.\n\nWhen first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of\nan arithmetic expression 2 \u0026lt;\u0026lt; (netmask - mask_bits - 1) is subject\nto overflow due to a failure casting operands to a larger data type\nbefore performing the arithmetic.\n\nNote that it\u0026apos;s harmless since the value will be checked at the next step.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.(CVE-2023-53032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before truncation in jfs_truncate_nolock()\n\nAdded a check for \u0026quot;read-only\u0026quot; mode in the `jfs_truncate_nolock`\nfunction to avoid errors related to writing to a read-only\nfilesystem.\n\nCall stack:\n\nblock_write_begin() {\n jfs_write_failed() {\n jfs_truncate() {\n jfs_truncate_nolock() {\n txEnd() {\n ...\n log = JFS_SBI(tblk-\u0026gt;sb)-\u0026gt;log;\n // (log == NULL)\n\nIf the `isReadOnly(ip)` condition is triggered in\n`jfs_truncate_nolock`, the function execution will stop, and no\nfurther data modification will occur. Instead, the `xtTruncate`\nfunction will be called with the \u0026quot;COMMIT_WMAP\u0026quot; flag, preventing\nmodifications in \u0026quot;read-only\u0026quot; mode.(CVE-2024-58094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: extend RCU protection in igmp6_send()\n\nigmp6_send() can be called without RTNL or RCU being held.\n\nExtend RCU protection so that we can safely fetch the net pointer\nand avoid a potential UAF.\n\nNote that we no longer can use sock_alloc_send_skb() because\nipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.\n\nInstead use alloc_skb() and charge the net-\u0026gt;ipv6.igmp_sk\nsocket under RCU protection.(CVE-2025-21759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nndisc: extend RCU protection in ndisc_send_skb()\n\nndisc_send_skb() can be called without RTNL or RCU held.\n\nAcquire rcu_read_lock() earlier, so that we can use dev_net_rcu()\nand avoid a potential UAF.(CVE-2025-21760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: use RCU protection in ovs_vport_cmd_fill_info()\n\novs_vport_cmd_fill_info() can be called without RTNL or RCU.\n\nUse RCU protection and dev_net_rcu() to avoid potential UAF.(CVE-2025-21761)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narp: use RCU protection in arp_xmit()\n\narp_xmit() can be called without RTNL or RCU protection.\n\nUse RCU protection to avoid potential UAF.(CVE-2025-21762)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nneighbour: use RCU protection in __neigh_notify()\n\n__neigh_notify() can be called without RTNL or RCU protection.\n\nUse RCU protection to avoid potential UAF.(CVE-2025-21763)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nndisc: use RCU protection in ndisc_alloc_skb()\n\nndisc_alloc_skb() can be called without RTNL or RCU being held.\n\nAdd RCU protection to avoid possible UAF.(CVE-2025-21764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()\n\nWhen performing an iSCSI boot using IPv6, iscsistart still reads the\n/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix\nlength is 64, this causes the shift exponent to become negative,\ntriggering a UBSAN warning. As the concept of a subnet mask does not\napply to IPv6, the value is set to ~0 to suppress the warning message.(CVE-2025-21993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atm: fix use after free in lec_send()\n\nThe -\u0026gt;send() operation frees skb so save the length before calling\n-\u0026gt;send() to avoid a use after free.(CVE-2025-22004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix use-after-free in print_graph_function_flags during tracer switching\n\nKairui reported a UAF issue in print_graph_function_flags() during\nftrace stress testing [1]. This issue can be reproduced if puting a\n\u0026apos;mdelay(10)\u0026apos; after \u0026apos;mutex_unlock(\u0026amp;trace_types_lock)\u0026apos; in s_start(),\nand executing the following script:\n\n $ echo function_graph \u0026gt; current_tracer\n $ cat trace \u0026gt; /dev/null \u0026amp;\n $ sleep 5 # Ensure the \u0026apos;cat\u0026apos; reaches the \u0026apos;mdelay(10)\u0026apos; point\n $ echo timerlat \u0026gt; current_tracer\n\nThe root cause lies in the two calls to print_graph_function_flags\nwithin print_trace_line during each s_show():\n\n * One through \u0026apos;iter-\u0026gt;trace-\u0026gt;print_line()\u0026apos;;\n * Another through \u0026apos;event-\u0026gt;funcs-\u0026gt;trace()\u0026apos;, which is hidden in\n print_trace_fmt() before print_trace_line returns.\n\nTracer switching only updates the former, while the latter continues\nto use the print_line function of the old tracer, which in the script\nabove is print_graph_function_flags.\n\nMoreover, when switching from the \u0026apos;function_graph\u0026apos; tracer to the\n\u0026apos;timerlat\u0026apos; tracer, s_start only calls graph_trace_close of the\n\u0026apos;function_graph\u0026apos; tracer to free \u0026apos;iter-\u0026gt;private\u0026apos;, but does not set\nit to NULL. This provides an opportunity for \u0026apos;event-\u0026gt;funcs-\u0026gt;trace()\u0026apos;\nto use an invalid \u0026apos;iter-\u0026gt;private\u0026apos;.\n\nTo fix this issue, set \u0026apos;iter-\u0026gt;private\u0026apos; to NULL immediately after\nfreeing it in graph_trace_close(), ensuring that an invalid pointer\nis not passed to other tracers. Additionally, clean up the unnecessary\n\u0026apos;iter-\u0026gt;private = NULL\u0026apos; during each \u0026apos;cat trace\u0026apos; when using wakeup and\nirqsoff tracers.\n\n [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/(CVE-2025-22035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix geneve_opt length integer overflow\n\nstruct geneve_opt uses 5 bit length for each single option, which\nmeans every vary size option should be smaller than 128 bytes.\n\nHowever, all current related Netlink policies cannot promise this\nlength condition and the attacker can exploit a exact 128-byte size\noption to *fake* a zero length option and confuse the parsing logic,\nfurther achieve heap out-of-bounds read.\n\nOne example crash log is like below:\n\n[ 3.905425] ==================================================================\n[ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0\n[ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177\n[ 3.906646]\n[ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1\n[ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[ 3.907784] Call Trace:\n[ 3.907925] \u0026lt;TASK\u0026gt;\n[ 3.908048] dump_stack_lvl+0x44/0x5c\n[ 3.908258] print_report+0x184/0x4be\n[ 3.909151] kasan_report+0xc5/0x100\n[ 3.909539] kasan_check_range+0xf3/0x1a0\n[ 3.909794] memcpy+0x1f/0x60\n[ 3.909968] nla_put+0xa9/0xe0\n[ 3.910147] tunnel_key_dump+0x945/0xba0\n[ 3.911536] tcf_action_dump_1+0x1c1/0x340\n[ 3.912436] tcf_action_dump+0x101/0x180\n[ 3.912689] tcf_exts_dump+0x164/0x1e0\n[ 3.912905] fw_dump+0x18b/0x2d0\n[ 3.913483] tcf_fill_node+0x2ee/0x460\n[ 3.914778] tfilter_notify+0xf4/0x180\n[ 3.915208] tc_new_tfilter+0xd51/0x10d0\n[ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560\n[ 3.919118] netlink_rcv_skb+0xcd/0x200\n[ 3.919787] netlink_unicast+0x395/0x530\n[ 3.921032] netlink_sendmsg+0x3d0/0x6d0\n[ 3.921987] __sock_sendmsg+0x99/0xa0\n[ 3.922220] __sys_sendto+0x1b7/0x240\n[ 3.922682] __x64_sys_sendto+0x72/0x90\n[ 3.922906] do_syscall_64+0x5e/0x90\n[ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 3.924122] RIP: 0033:0x7e83eab84407\n[ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\n[ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407\n[ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003\n[ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c\n[ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0\n[ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8\n\nFix these issues by enforing correct length condition in related\npolicies.(CVE-2025-22055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero. However, it occasionally spiked to 524,288 pages\nand never dropped. Moreover, the value doubled when the application was\nterminated. Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n 1. /proc/net/sockstat reports 0 pages\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 0\n\n 2. Run the script till the report reaches 524,288\n\n # python3 test.py \u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 3 mem 524288 \u0026lt;-- (INT_MAX + 1) \u0026gt;\u0026gt; PAGE_SHIFT\n\n 3. Kill the socket and confirm the number never drops\n\n # pkill python3 \u0026amp;\u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 524288\n\n 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n # python3 test.py \u0026amp; sleep 1 \u0026amp;\u0026amp; pkill python3\n\n 5. The number doubles\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb-\u0026gt;truesize in the queue. This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting. However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n 1) Add size to sk-\u0026gt;sk_forward_alloc.\n 2) Round down sk-\u0026gt;sk_forward_alloc to the nearest lower multiple of\n PAGE_SIZE and assign it to amount.\n 3) Subtract amount from sk-\u0026gt;sk_forward_alloc.\n 4) Pass amount \u0026gt;\u0026gt; PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk-\u0026gt;sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount. 3) reverts the wraparound, so we don\u0026apos;t\nsee a warning in inet_sock_destruct(). However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 (\u0026quot;net: implement per-cpu reserves for\nmemory_allocated\u0026quot;), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket\u0026apos;s\nsk-\u0026gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let\u0026apos;s use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind((\u0026apos;\u0026apos;, 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b\u0026apos;a\u0026apos; * 100\n\nwhile True:\n c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1,raid10: don\u0026apos;t ignore IO flags\n\nIf blk-wbt is enabled by default, it\u0026apos;s found that raid write performance\nis quite bad because all IO are throttled by wbt of underlying disks,\ndue to flag REQ_IDLE is ignored. And turns out this behaviour exist since\nblk-wbt is introduced.\n\nOther than REQ_IDLE, other flags should not be ignored as well, for\nexample REQ_META can be set for filesystems, clearing it can cause priority\nreverse problems; And REQ_NOWAIT should not be cleared as well, because\nio will wait instead of failing directly in underlying disks.\n\nFix those problems by keep IO flags from master bio.\n\nFises: f51d46d0e7cb (\u0026quot;md: add support for REQ_NOWAIT\u0026quot;)(CVE-2025-22125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)",
"id": "OESA-2025-1465",
"modified": "2026-08-06T11:08:33Z",
"published": "2025-05-09T11:08:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47641"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49217"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49232"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49298"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49385"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49429"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49626"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49647"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52935"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53023"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53032"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58094"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21761"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21762"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21763"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21764"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2020-36789",
"CVE-2021-47641",
"CVE-2021-47668",
"CVE-2021-47670",
"CVE-2022-49084",
"CVE-2022-49086",
"CVE-2022-49217",
"CVE-2022-49232",
"CVE-2022-49298",
"CVE-2022-49385",
"CVE-2022-49429",
"CVE-2022-49626",
"CVE-2022-49647",
"CVE-2023-52935",
"CVE-2023-53019",
"CVE-2023-53023",
"CVE-2023-53032",
"CVE-2024-58094",
"CVE-2025-21759",
"CVE-2025-21760",
"CVE-2025-21761",
"CVE-2025-21762",
"CVE-2025-21763",
"CVE-2025-21764",
"CVE-2025-21993",
"CVE-2025-22004",
"CVE-2025-22035",
"CVE-2025-22055",
"CVE-2025-22058",
"CVE-2025-22125",
"CVE-2025-37785"
]
}
OESA-2025-2765 (CVE-2024-36357)
Vulnerability from osv_openeuler – Published: 2025-11-28 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Prevent integer overflow in hdr_first_de()
The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow.(CVE-2025-22080)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()
A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash.
Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed.
This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue").
This is found by our static analysis tool KNighter.(CVE-2025-37828)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: csa unmap use uninterruptible lock
After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace.
Change to use uninterruptible wait lock fix the issue.
WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: <TASK> drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0
(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)(CVE-2025-38011)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: unshare page tables during VMA split, not before
Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split.
Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked.
An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts:
- from hugetlb_split(), holding:
- mmap lock (exclusively)
- VMA lock
- file rmap lock (exclusively)
- hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock
Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back.
[(CVE-2025-38084)
In the Linux kernel, the following vulnerability has been resolved:
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork().
io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference.
There are two issues, which lead to that problem:
1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork().
2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated.
This happens when a kernel thread is created in the context of
a user space thread, which has TIF_IO_BITMAP set as the thread
flags are copied and the IO bitmap pointer is cleared.
Other than in the failed fork() case this has no impact because
kernel threads including IO workers never return to user space and
therefore never invoke tss_update_io_bitmap().
Cure this by adding the missing cleanups and checks:
1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task.
2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().
For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.(CVE-2025-38100)
In the Linux kernel, the following vulnerability has been resolved:
crypto: marvell/cesa - Handle zero-length skcipher requests
Do not access random memory for zero-length skcipher requests. Just return 0.(CVE-2025-38173)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var
If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var.
================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================
The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38214)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix crash when rebind ccp device for ccp.ko
When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash:
$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind
[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device.
Tested on AMD Ryzen 7 1700X.(CVE-2025-38581)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix null pointer access
Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.(CVE-2025-38705)
In the Linux kernel, the following vulnerability has been resolved:
net: kcm: Fix race condition in kcm_unattach()
syzbot found a race condition when kcm_unattach(psock) and kcm_release(kcm) are executed at the same time.
kcm_unattach() is missing a check of the flag kcm->tx_stopped before calling queue_work().
If the kcm has a reserved psock, kcm_unattach() might get executed between cancel_work_sync() and unreserve_psock() in kcm_release(), requeuing kcm->tx_work right before kcm gets freed in kcm_done().
Remove kcm->tx_stopped and replace it by the less error-prone disable_work_sync().(CVE-2025-38717)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
In the Linux kernel, the following vulnerability has been resolved:
smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()
We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()!
Otherwise already existing connections try to use smb_direct_wq as a NULL pointer.(CVE-2025-39692)
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Fix SCCB present check
Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation.
If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping.
Fix this by introducing a function that handles the NULL case before address translation.(CVE-2025-39694)
In the Linux kernel, the following vulnerability has been resolved:
net, hsr: reject HSR frame if skb can't hold tag
Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG):
[ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0
<snip registers, remove unreliable trace>
[ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ>
This issue was found by syzkaller.
The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics.
The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG).
Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers.
Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit().
In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network.
Further Details:
In the reproducer, the following network interface chain is set up:
┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘
To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---(CVE-2025-39703)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39751)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Set merge to zero early in af_alg_sendmsg
If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done.
Fix this by setting ctx->merge to zero near the start of the loop.(CVE-2025-39931)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed
If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and "dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception:
qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0(CVE-2025-39938)
In the Linux kernel, the following vulnerability has been resolved:
dm-stripe: fix a possible integer overflow
There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;(CVE-2025-39940)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg
Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state.
Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.(CVE-2025-39964)
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: check for stable address space before operating on the VMA
It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault
The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup().
2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation.
3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap().
4) swapoff is tried on the
'mm' added to the 'mmlist' as
part of the 2.
5) unuse_mm(), that iterates
through the vma's of this 'mm'
will hit the non-NULL zero entry
and operating on this zero entry
as a vma is resulting into the
oops.
The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap().
Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.(CVE-2025-39992)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix warning in smc_rx_splice() when calling get_page()
smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are later passed to get_page() in smc_rx_splice(). Since kmalloc memory is not page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents holding a refcount on the buffer. This can lead to use-after-free if the memory is released before splice_to_pipe() completes.
Use folio_alloc() instead, ensuring DMBs are page-backed and safe for get_page().
WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc] CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE Hardware name: IBM 3931 A01 704 (z/VM 7.4.0) Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8 Krnl Code: 0007931610326960: af000000 mc 0,0 0007931610326964: a7f4ff43 brc 15,00079316103267ea #0007931610326968: af000000 mc 0,0 >000793161032696c: a7f4ff3f brc 15,00079316103267ea 0007931610326970: e320f1000004 lg %r2,256(%r15) 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560 000793161032697c: a7f4fbb5 brc 15,00079316103260e6 0007931610326980: b904002b lgr %r2,%r11 Call Trace: smc_rx_splice+0xafc/0xe20 [smc] smc_rx_splice+0x756/0xe20 [smc]) smc_rx_recvmsg+0xa74/0xe00 [smc] smc_splice_read+0x1ce/0x3b0 [smc] sock_splice_read+0xa2/0xf0 do_splice_read+0x198/0x240 splice_file_to_pipe+0x7e/0x110 do_splice+0x59e/0xde0 __do_splice+0x11a/0x2d0 __s390x_sys_splice+0x140/0x1f0 __do_syscall+0x122/0x280 system_call+0x6e/0x90 Last Breaking-Event-Address: smc_rx_splice+0x960/0xe20 [smc] ---[ end trace 0000000000000000 ]---(CVE-2025-40012)
In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak
Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace.
Initialize ff_up_compat to zero before filling valid fields.(CVE-2025-40035)
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: nci: Add parameter validation for packet data
Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").
This bug arises due to very limited and poor input validation
that was done at nic_valid_size(). This validation only
validates the skb->len (directly reflects size provided at the
userspace interface) with the length provided in the buffer
itself (interpreted as NCI_HEADER). This leads to the processing
of memory content at the address assuming the correct layout
per what opcode requires there. This leads to the accesses to
buffer of skb_buff->data which is not assigned anything yet.
Following the same silent drop of packets of invalid sizes at
nic_valid_size(), add validation of the data in the respective
handlers and return error values in case of failure. Release
the skb if error values are returned from handlers in
nci_nft_packet and effectively do a silent drop
Possible TODO: because we silently drop the packets, the
call to nci_request will be waiting for completion of request
and will face timeouts. These timeouts can get excessively logged
in the dmesg. A proper handling of them may require to export
nci_request_cancel (or propagate error handling from the
nft packets handlers).(CVE-2025-40043)
In the Linux kernel, a race condition vulnerability exists in the uio_hv_generic driver. The driver's default interrupt mask setting logic is flawed, as the interrupt mask value should be completely controlled by user space. If the mask bit gets changed by the driver concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, causing the user-mode driver to miss an interrupt and leading to a system hang.
Specifically, when the driver sets the inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. This results in the host putting a message into the ring buffer without interruption. Subsequently, when user space code in the guest sets the inbound ring buffer interrupt mask to 0 and waits for an interrupt via pread(), since there's already a message in the ring buffer, no new interrupt is generated, causing pread() to wait indefinitely.
The fix removes all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable user space control of the interrupt mask by writing 0/1 to /dev/uioX.(CVE-2025-40048)
In the Linux kernel, the following vulnerability has been resolved:
net: dlink: handle copy_thresh allocation failure
The driver did not handle failure of netdev_alloc_skb_ip_align().
If the allocation failed, dereferencing skb->protocol could lead to
a NULL pointer dereference.
This patch tries to allocate skb. If the allocation fails, it falls
back to the normal path.
Tested-on: D-Link DGE-550T Rev-A3(CVE-2025-40053)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix double free in user_cluster_connect()
user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free.(CVE-2025-40055)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290
CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3 RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000 RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 </TASK>
Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
When hfsplus_uni2asc is called from hfsplus_listxattr, it actually passes in a struct hfsplus_attr_unistr*. The size of the corresponding structure is different from that of hfsplus_unistr, so the previous fix (94458781aee6) is insufficient. The pointer on the unicode buffer is still going beyond the allocated memory.
This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and hfsplus_uni2asc_str to process two unicode buffers, struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively. When ustrlen value is bigger than the allocated memory size, the ustrlen value is limited to an safe size.(CVE-2025-40082)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: transport_ipc: validate payload size before reading handle
handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing.
This is a minimal fix to guard the initial handle read.(CVE-2025-40084)
In the Linux kernel, a buffer overflow vulnerability exists in the hfsplus_strcasecmp() function of the hfsplus filesystem. When the hfsplus_strcasecmp() logic is triggered, it causes a slab-out-of-bounds read, allowing attackers to read sensitive information from kernel memory. This vulnerability triggers KASAN-detected boundary check errors and could be exploited for information disclosure or system crash attacks.(CVE-2025-40088)
In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present. Ensure that set_ent is always set since only drbg provides it. The Linux kernel CVE team has assigned CVE-2025-40109 to this issue.(CVE-2025-40109)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix a null-ptr access in the cursor snooper
Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it.
vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean "no surface", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it.
Fixes unchecked null-ptr reference in the snooping code.(CVE-2025-40110)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock
Prevent USB runtime PM (autosuspend) for AX88772* in bind.
usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend.
The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues.
To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides.
Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before.(CVE-2025-40120)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Enforce expected_attach_type for tailcall compatibility
Yinhao et al. recently reported:
Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.
The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls.
The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.
In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible().
Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run() and cpu_map_bpf_prog_run() which set up a new environment / context and therefore these situations are not prone to this issue.(CVE-2025-40123)
In the Linux kernel, a vulnerability exists in the blk-mq component: the return value of blk_mq_sysfs_register_hctxs() is not checked in __blk_mq_update_nr_hw_queues() function. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger kernel warnings. The issue occurs because kobject_del() is called unconditionally even when sysfs creation fails, leading to kernfs directory operation errors.(CVE-2025-40125)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix null pointer dereference on zero-length checksum
In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes checksum.data to be set to NULL. This triggers a NPD when accessing checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that the value of checksum.len is not less than XDR_UNIT.(CVE-2025-40129)
In the Linux kernel, there is a race condition between device manager (dm) suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes, causing q->tag_set to be a NULL pointer and leading to system crash. The vulnerability affects Linux kernel versions from 5.0 to 6.17.2.(CVE-2025-40134)
In the Linux kernel, a race condition vulnerability exists in the rtl8150 USB network driver's rtl8150_set_multicast function. The vulnerability occurs because rtl8150_set_multicast incorrectly calls netif_stop_queue and netif_wake_queue, causing TX queue synchronization issues. When rtl8150_set_multicast wakes up the TX queue before USB transfer completion, it may lead to double submission of URB in rtl8150_start_xmit, resulting in warnings and potential system instability.(CVE-2025-40140)
In the Linux kernel, a use-after-free vulnerability has been identified in the Bluetooth ISO module. This vulnerability is similar to the issue in sco_conn_free where if conn->sk is not set to NULL, it may lead to use-after-free in iso_conn_free.(CVE-2025-40141)
A vulnerability was found in the Linux kernel where calling mprotect() on large hugetlb memory areas (approximately 300GB) can cause soft lockup issues. The CPU becomes stuck for extended periods, making the system unresponsive. This occurs because the hugetlb handling for large memory lacks proper scheduling opportunities, unlike THP or base pages which already have cond_resched() calls. Although the soft lockup was triggered by MTE, this is not MTE-specific - any processing that takes a long time in the loop may trigger soft lockup.(CVE-2025-40153)
In the Linux kernel, the usbnet driver contains a stack-based buffer overflow vulnerability. Syzbot reported warnings about using smp_processor_id() in preemptible code. This vulnerability may lead to stack buffer overflow, affecting system confidentiality, integrity, and availability. The vulnerability stems from the incorrect use of smp_processor_id() function in the usbnet_skb_return function within preemptible context.(CVE-2025-40164)
In the Linux kernel, a vulnerability has been found in the ext4 filesystem. When opening a verity file on a corrupted ext4 filesystem mounted without a journal, syzbot reported a BUG_ON in ext4_es_cache_extent(). The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set. This is an invalid combination since an inode should have either: INLINE_DATA (data stored directly in the inode) or EXTENTS (data stored in extent-mapped blocks). Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes.(CVE-2025-40167)
In the Linux kernel, the check_alu_op() function in the BPF verifier contains a vulnerability when validating ALU operation instructions. The function validates BPF program instructions where the 'offset' field is a signed 16-bit integer. The original check condition 'insn->off > 1' was intended to ensure the offset is either 0 or 1 (for BPF_MOD/BPF_DIV operations). However, since 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This vulnerability allows maliciously crafted BPF programs to bypass verification, potentially leading to privilege escalation and other security issues.(CVE-2025-40169)
In the Linux kernel, a vulnerability has been found in the nvmet-fc module. When multiple async commands are in flight from __nvmet_fc_send_ls_req, a tgtport reference is taken for each command. In the current code, only one put work item is queued at a time, which results in a leaked reference. This vulnerability affects multiple Linux kernel version branches.(CVE-2025-40171)
In the Linux kernel, a vulnerability has been identified in the net/ip6_tunnel module. Similar to IPv4 tunnel, IPv6 version also updates dev->needed_headroom. While IPv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd, the IPv6 tunnel continues to increase headroom without any ceiling. This vulnerability may lead to perpetual tunnel growth, affecting system confidentiality, integrity, and availability, with potential privilege escalation risks.(CVE-2025-40173)
In the Linux kernel, during asynchronous decryption in the TLS module, the tls_strp_msg_hold function is called to create a clone of the input skb to hold references to the memory it uses. If the allocation of this clone fails, proceeding with asynchronous decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, the system should wait for all pending decryption requests to complete.(CVE-2025-40176)
In the Linux kernel, there is a NULL pointer dereference vulnerability in the pid_nr_ns function. When task_active_pid_ns returns null, it triggers kernel panic. The vulnerability manifests as kernel panic when task_active_pid_ns returns null in the pid_nr_ns function. The vulnerability example shows inability to handle kernel NULL pointer dereference errors, leading to system crash. The specific error is 'Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058', ultimately causing kernel panic and system crash.(CVE-2025-40178)
In the Linux kernel, the ext4 filesystem has a vulnerability: orphan files can be arbitrarily large in principle. However, orphan replay needs to traverse all content and pin all buffers in memory. Filesystems with absurdly large orphan files can lead to significant memory consumption. The vulnerability limits orphan file size to a sane value and uses kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for large orphan files.(CVE-2025-40179)
In the Linux kernel, a memory leak vulnerability exists. Cilium's BPF egress gateway feature redirects K8s Pod traffic through vxlan tunnels to dedicated egress gateways. When using the bpf_redirect_neigh() helper to forward packets, vxlan allocates metadata_dst objects and attaches them to skb through fake dst entries. However, since bpf_redirect_neigh() only sets new dst entries without first dropping existing ones, the metadata_dst objects are never released, causing continuous increase in kmalloc-256 slab usage.(CVE-2025-40183)
In the Linux kernel, a NULL pointer dereference vulnerability exists in the SCTP protocol. When new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0, and sctp_ulpevent_make_authkey() returns 0, the variable ai_ev remains zero and this zero value will be dereferenced in the sctp_ulpevent_free() function.(CVE-2025-40187)
In the Linux kernel, there is a reference count underflow vulnerability in the ext4 file system. Syzkaller discovered a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1), causing the refcount to underflow and proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow, EXT4-fs warning: ea_inode dec ref err. The fix makes the invariant explicit: if the current refcount is non-positive, treat it as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount.(CVE-2025-40190)
In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected". This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.(CVE-2025-40192)
In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request(). The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.(CVE-2025-40194)
In the Linux kernel, a buffer over-read vulnerability has been discovered in the parse_apply_sb_mount_options() function of the ext4 filesystem. Unlike other strings in the ext4 superblock, this vulnerability relies on tune2fs to ensure s_mount_opts is NUL terminated. The parse_apply_sb_mount_options() function has been hardened by treating s_mount_opts as a potential __nonstring.(CVE-2025-40198)
In the Linux kernel, a vulnerability has been identified in the Squashfs filesystem's squashfs_read_inode() function, which fails to properly validate input data and may accept negative file sizes. Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size. This commit fixes the issue by checking for negative file sizes and returning EINVAL.(CVE-2025-40200)
In the Linux kernel, the sys_prlimit64() path has a race condition issue with the usage of task_lock(tsk->group_leader). When tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). The fix changes sys_prlimit64() to take tasklist_lock when necessary.(CVE-2025-40201)
In the Linux kernel, the IPMI subsystem's user message limit handling had a number of issues, including improper counting in some cases and a use-after-free vulnerability. The vulnerability has been resolved by restructuring the handling to manage more in the receive message allocation routine, where all referencing and user message limit counts are now handled, making the process cleaner and safer. This vulnerability affects Linux Kernel versions from 5.19 to 6.18-rc1.(CVE-2025-40202)
In the Linux kernel, the SCTP protocol's MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)
In the Linux kernel, the netfilter nft_objref module has a validation bypass vulnerability. Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls. This vulnerability allows attackers to trigger kernel stack overflow through specially crafted nftables rules, leading to system crash. Validation functions for objref and objrefmap expressions have been implemented, currently only NFT_OBJECT_SYNPROXY object type requires validation.(CVE-2025-40206)
In the Linux kernel, a use-after-free vulnerability exists in the ACPI video subsystem. The switch_brightness_work delayed work accesses device->brightness and device->backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. The issue is fixed by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work, ensuring the work completes before the memory is freed.(CVE-2025-40211)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-source-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"perf-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"python3-perf-6.6.0-121.0.0.111.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-121.0.0.111.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-121.0.0.111.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-source-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"perf-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"python3-perf-6.6.0-121.0.0.111.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-121.0.0.111.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-121.0.0.111.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nA transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Prevent integer overflow in hdr_first_de()\n\nThe \u0026quot;de_off\u0026quot; and \u0026quot;used\u0026quot; variables come from the disk so they both need to\ncheck. The problem is that on 32bit systems if they\u0026apos;re both greater than\nUINT_MAX - 16 then the check does work as intended because of an integer\noverflow.(CVE-2025-22080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()\n\nA race can occur between the MCQ completion path and the abort handler:\nonce a request completes, __blk_mq_free_request() sets rq-\u0026gt;mq_hctx to\nNULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in\nufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is\ndereferenced, the kernel will crash.\n\nAdd a NULL check for the returned hwq pointer. If hwq is NULL, log an\nerror and return FAILED, preventing a potential NULL-pointer\ndereference. As suggested by Bart, the ufshcd_cmd_inflight() check is\nremoved.\n\nThis is similar to the fix in commit 74736103fb41 (\u0026quot;scsi: ufs: core: Fix\nufshcd_abort_one racing issue\u0026quot;).\n\nThis is found by our static analysis tool KNighter.(CVE-2025-37828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: csa unmap use uninterruptible lock\n\nAfter process exit to unmap csa and free GPU vm, if signal is accepted\nand then waiting to take vm lock is interrupted and return, it causes\nmemory leaking and below warning backtrace.\n\nChange to use uninterruptible wait lock fix the issue.\n\nWARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525\n amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n drm_file_free.part.0+0x1da/0x230 [drm]\n drm_close_helper.isra.0+0x65/0x70 [drm]\n drm_release+0x6a/0x120 [drm]\n amdgpu_drm_release+0x51/0x60 [amdgpu]\n __fput+0x9f/0x280\n ____fput+0xe/0x20\n task_work_run+0x67/0xa0\n do_exit+0x217/0x3c0\n do_group_exit+0x3b/0xb0\n get_signal+0x14a/0x8d0\n arch_do_signal_or_restart+0xde/0x100\n exit_to_user_mode_loop+0xc1/0x1a0\n exit_to_user_mode_prepare+0xf4/0x100\n syscall_exit_to_user_mode+0x17/0x40\n do_syscall_64+0x69/0xc0\n\n(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)(CVE-2025-38011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: unshare page tables during VMA split, not before\n\nCurrently, __split_vma() triggers hugetlb page table unsharing through\nvm_ops-\u0026gt;may_split(). This happens before the VMA lock and rmap locks are\ntaken - which is too early, it allows racing VMA-locked page faults in our\nprocess and racing rmap walks from other processes to cause page tables to\nbe shared again before we actually perform the split.\n\nFix it by explicitly calling into the hugetlb unshare logic from\n__split_vma() in the same place where THP splitting also happens. At that\npoint, both the VMA and the rmap(s) are write-locked.\n\nAn annoying detail is that we can now call into the helper\nhugetlb_unshare_pmds() from two different locking contexts:\n\n1. from hugetlb_split(), holding:\n - mmap lock (exclusively)\n - VMA lock\n - file rmap lock (exclusively)\n2. hugetlb_unshare_all_pmds(), which I think is designed to be able to\n call us with only the mmap lock held (in shared mode), but currently\n only runs while holding mmap lock (exclusively) and VMA lock\n\nBackporting note:\nThis commit fixes a racy protection that was introduced in commit\nb30c14cd6102 (\u0026quot;hugetlb: unshare some PMDs when splitting VMAs\u0026quot;); that\ncommit claimed to fix an issue introduced in 5.13, but it should actually\nalso go all the way back.\n\n[(CVE-2025-38084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/iopl: Cure TIF_IO_BITMAP inconsistencies\n\nio_bitmap_exit() is invoked from exit_thread() when a task exists or\nwhen a fork fails. In the latter case the exit_thread() cleans up\nresources which were allocated during fork().\n\nio_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up\nin tss_update_io_bitmap(). tss_update_io_bitmap() operates on the\ncurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,\ntss_update_io_bitmap() crashes with a NULL pointer dereference.\n\nThere are two issues, which lead to that problem:\n\n 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when\n the task, which is cleaned up, is not the current task. That\u0026apos;s a\n clear indicator for a cleanup after a failed fork().\n\n 2) A task should not have TIF_IO_BITMAP set and neither a bitmap\n installed nor IOPL emulation level 3 activated.\n\n This happens when a kernel thread is created in the context of\n a user space thread, which has TIF_IO_BITMAP set as the thread\n flags are copied and the IO bitmap pointer is cleared.\n\n Other than in the failed fork() case this has no impact because\n kernel threads including IO workers never return to user space and\n therefore never invoke tss_update_io_bitmap().\n\nCure this by adding the missing cleanups and checks:\n\n 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if\n the to be cleaned up task is not the current task.\n\n 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user\n space forks it is set later, when the IO bitmap is inherited in\n io_bitmap_share().\n\nFor paranoia sake, add a warning into tss_update_io_bitmap() to catch\nthe case, when that code is invoked with inconsistent state.(CVE-2025-38100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: marvell/cesa - Handle zero-length skcipher requests\n\nDo not access random memory for zero-length skcipher requests.\nJust return 0.(CVE-2025-38173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var\n\nIf fb_add_videomode() in fb_set_var() fails to allocate memory for\nfb_videomode, later it may lead to a null-ptr dereference in\nfb_videomode_to_var(), as the fb_info is registered while not having the\nmode in modelist that is expected to be there, i.e. the one that is\ndescribed in fb_info-\u0026gt;var.\n\n================================================================\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901\nCall Trace:\n display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929\n fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071\n resize_screen drivers/tty/vt/vt.c:1176 [inline]\n vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263\n fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720\n fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776\n do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128\n fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203\n vfs_ioctl fs/ioctl.c:48 [inline]\n __do_sys_ioctl fs/ioctl.c:753 [inline]\n __se_sys_ioctl fs/ioctl.c:739 [inline]\n __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739\n do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x67/0xd1\n================================================================\n\nThe reason is that fb_info-\u0026gt;var is being modified in fb_set_var(), and\nthen fb_videomode_to_var() is called. If it fails to add the mode to\nfb_info-\u0026gt;modelist, fb_set_var() returns error, but does not restore the\nold value of fb_info-\u0026gt;var. Restore fb_info-\u0026gt;var on failure the same way\nit is done earlier in the function.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Fix crash when rebind ccp device for ccp.ko\n\nWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding\nthe ccp device causes the following crash:\n\n$ echo \u0026apos;0000:0a:00.2\u0026apos; \u0026gt; /sys/bus/pci/drivers/ccp/unbind\n$ echo \u0026apos;0000:0a:00.2\u0026apos; \u0026gt; /sys/bus/pci/drivers/ccp/bind\n\n[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[ 204.978026] #PF: supervisor write access in kernel mode\n[ 204.979126] #PF: error_code(0x0002) - not-present page\n[ 204.980226] PGD 0 P4D 0\n[ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI\n...\n[ 204.997852] Call Trace:\n[ 204.999074] \u0026lt;TASK\u0026gt;\n[ 205.000297] start_creating+0x9f/0x1c0\n[ 205.001533] debugfs_create_dir+0x1f/0x170\n[ 205.002769] ? srso_return_thunk+0x5/0x5f\n[ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp]\n[ 205.005241] ccp5_init+0x8b2/0x960 [ccp]\n[ 205.006469] ccp_dev_init+0xd4/0x150 [ccp]\n[ 205.007709] sp_init+0x5f/0x80 [ccp]\n[ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp]\n[ 205.010165] ? srso_return_thunk+0x5/0x5f\n[ 205.011376] local_pci_probe+0x4f/0xb0\n[ 205.012584] pci_device_probe+0xdb/0x230\n[ 205.013810] really_probe+0xed/0x380\n[ 205.015024] __driver_probe_device+0x7e/0x160\n[ 205.016240] device_driver_attach+0x2f/0x60\n[ 205.017457] bind_store+0x7c/0xb0\n[ 205.018663] drv_attr_store+0x28/0x40\n[ 205.019868] sysfs_kf_write+0x5f/0x70\n[ 205.021065] kernfs_fop_write_iter+0x145/0x1d0\n[ 205.022267] vfs_write+0x308/0x440\n[ 205.023453] ksys_write+0x6d/0xe0\n[ 205.024616] __x64_sys_write+0x1e/0x30\n[ 205.025778] x64_sys_call+0x16ba/0x2150\n[ 205.026942] do_syscall_64+0x56/0x1e0\n[ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 205.029276] RIP: 0033:0x7fbc36f10104\n[ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5\n\nThis patch sets ccp_debugfs_dir to NULL after destroying it in\nccp5_debugfs_destroy, allowing the directory dentry to be\nrecreated when rebinding the ccp device.\n\nTested on AMD Ryzen 7 1700X.(CVE-2025-38581)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: fix null pointer access\n\nWriting a string without delimiters (\u0026apos; \u0026apos;, \u0026apos;\\n\u0026apos;, \u0026apos;\\0\u0026apos;) to the under\ngpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile\nwill result in a null pointer dereference.(CVE-2025-38705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: kcm: Fix race condition in kcm_unattach()\n\nsyzbot found a race condition when kcm_unattach(psock)\nand kcm_release(kcm) are executed at the same time.\n\nkcm_unattach() is missing a check of the flag\nkcm-\u0026gt;tx_stopped before calling queue_work().\n\nIf the kcm has a reserved psock, kcm_unattach() might get executed\nbetween cancel_work_sync() and unreserve_psock() in kcm_release(),\nrequeuing kcm-\u0026gt;tx_work right before kcm gets freed in kcm_done().\n\nRemove kcm-\u0026gt;tx_stopped and replace it by the less\nerror-prone disable_work_sync().(CVE-2025-38717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()\n\nWe can\u0026apos;t call destroy_workqueue(smb_direct_wq); before stop_sessions()!\n\nOtherwise already existing connections try to use smb_direct_wq as\na NULL pointer.(CVE-2025-39692)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Fix SCCB present check\n\nTracing code called by the SCLP interrupt handler contains early exits\nif the SCCB address associated with an interrupt is NULL. This check is\nperformed after physical to virtual address translation.\n\nIf the kernel identity mapping does not start at address zero, the\nresulting virtual address is never zero, so that the NULL checks won\u0026apos;t\nwork. Subsequently this may result in incorrect accesses to the first\npage of the identity mapping.\n\nFix this by introducing a function that handles the NULL case before\naddress translation.(CVE-2025-39694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet, hsr: reject HSR frame if skb can\u0026apos;t hold tag\n\nReceiving HSR frame with insufficient space to hold HSR tag in the skb\ncan result in a crash (kernel BUG):\n\n[ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1\n[ 45.392559] ------------[ cut here ]------------\n[ 45.392912] kernel BUG at net/core/skbuff.c:211!\n[ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)\n[ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0\n\n\u0026lt;snip registers, remove unreliable trace\u0026gt;\n\n[ 45.402911] Call Trace:\n[ 45.403105] \u0026lt;IRQ\u0026gt;\n[ 45.404470] skb_push+0xcd/0xf0\n[ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0\n[ 45.406513] br_forward_finish+0x128/0x260\n[ 45.408483] __br_forward+0x42d/0x590\n[ 45.409464] maybe_deliver+0x2eb/0x420\n[ 45.409763] br_flood+0x174/0x4a0\n[ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0\n[ 45.411618] br_handle_frame+0xac3/0x1230\n[ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0\n[ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0\n[ 45.424478] __netif_receive_skb+0x22/0x170\n[ 45.424806] process_backlog+0x242/0x6d0\n[ 45.425116] __napi_poll+0xbb/0x630\n[ 45.425394] net_rx_action+0x4d1/0xcc0\n[ 45.427613] handle_softirqs+0x1a4/0x580\n[ 45.427926] do_softirq+0x74/0x90\n[ 45.428196] \u0026lt;/IRQ\u0026gt;\n\nThis issue was found by syzkaller.\n\nThe panic happens in br_dev_queue_push_xmit() once it receives a\ncorrupted skb with ETH header already pushed in linear data. When it\nattempts the skb_push() call, there\u0026apos;s not enough headroom and\nskb_push() panics.\n\nThe corrupted skb is put on the queue by HSR layer, which makes a\nsequence of unintended transformations when it receives a specific\ncorrupted HSR frame (with incomplete TAG).\n\nFix it by dropping and consuming frames that are not long enough to\ncontain both ethernet and hsr headers.\n\nAlternative fix would be to check for enough headroom before skb_push()\nin br_dev_queue_push_xmit().\n\nIn the reproducer, this is injected via AF_PACKET, but I don\u0026apos;t easily\nsee why it couldn\u0026apos;t be sent over the wire from adjacent network.\n\nFurther Details:\n\nIn the reproducer, the following network interface chain is set up:\n\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 veth0_to_hsr \u251c\u2500\u2500\u2500\u2524 hsr_slave0 \u253c\u2500\u2500\u2500\u2510\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\n \u2502 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u251c\u2500\u2524 hsr0 \u251c\u2500\u2500\u2500\u2510\n \u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502 \u2502\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 veth1_to_hsr \u253c\u2500\u2500\u2500\u2524 hsr_slave1 \u251c\u2500\u2500\u2500\u2518 \u2514\u2524 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u250c\u253c bridge \u2502\n \u2502\u2502 \u2502\n \u2502\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502\n \u2502 ... \u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\nTo trigger the events leading up to crash, reproducer sends a corrupted\nHSR fr\n---truncated---(CVE-2025-39703)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39751)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Set merge to zero early in af_alg_sendmsg\n\nIf an error causes af_alg_sendmsg to abort, ctx-\u0026gt;merge may contain\na garbage value from the previous loop. This may then trigger a\ncrash on the next entry into af_alg_sendmsg when it attempts to do\na merge that can\u0026apos;t be done.\n\nFix this by setting ctx-\u0026gt;merge to zero near the start of the loop.(CVE-2025-39931)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed\n\nIf earlier opening of source graph fails (e.g. ADSP rejects due to\nincorrect audioreach topology), the graph is closed and\n\u0026quot;dai_data-\u0026gt;graph[dai-\u0026gt;id]\u0026quot; is assigned NULL. Preparing the DAI for sink\ngraph continues though and next call to q6apm_lpass_dai_prepare()\nreceives dai_data-\u0026gt;graph[dai-\u0026gt;id]=NULL leading to NULL pointer\nexception:\n\n qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd\n qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1\n q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78\n q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22\n Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8\n ...\n Call trace:\n q6apm_graph_media_format_pcm+0x48/0x120 (P)\n q6apm_lpass_dai_prepare+0x110/0x1b4\n snd_soc_pcm_dai_prepare+0x74/0x108\n __soc_pcm_prepare+0x44/0x160\n dpcm_be_dai_prepare+0x124/0x1c0(CVE-2025-39938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-stripe: fix a possible integer overflow\n\nThere\u0026apos;s a possible integer overflow in stripe_io_hints if we have too\nlarge chunk size. Test if the overflow happened, and if it did, don\u0026apos;t set\nlimits-\u0026gt;io_min and limits-\u0026gt;io_opt;(CVE-2025-39940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Disallow concurrent writes in af_alg_sendmsg\n\nIssuing two writes to the same af_alg socket is bogus as the\ndata will be interleaved in an unpredictable fashion. Furthermore,\nconcurrent writes may create inconsistencies in the internal\nsocket state.\n\nDisallow this by adding a new ctx-\u0026gt;write field that indiciates\nexclusive ownership for writing.(CVE-2025-39964)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: check for stable address space before operating on the VMA\n\nIt is possible to hit a zero entry while traversing the vmas in unuse_mm()\ncalled from swapoff path and accessing it causes the OOPS:\n\nUnable to handle kernel NULL pointer dereference at virtual address\n0000000000000446--\u0026gt; Loading the memory from offset 0x40 on the\nXA_ZERO_ENTRY as address.\nMem abort info:\n ESR = 0x0000000096000005\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x05: level 1 translation fault\n\nThe issue is manifested from the below race between the fork() on a\nprocess and swapoff:\nfork(dup_mmap())\t\t\tswapoff(unuse_mm)\n--------------- -----------------\n1) Identical mtree is built using\n __mt_dup().\n\n2) copy_pte_range()--\u0026gt;\n\tcopy_nonpresent_pte():\n The dst mm is added into the\n mmlist to be visible to the\n swapoff operation.\n\n3) Fatal signal is sent to the parent\nprocess(which is the current during the\nfork) thus skip the duplication of the\nvmas and mark the vma range with\nXA_ZERO_ENTRY as a marker for this process\nthat helps during exit_mmap().\n\n\t\t\t\t 4) swapoff is tried on the\n\t\t\t\t\t\u0026apos;mm\u0026apos; added to the \u0026apos;mmlist\u0026apos; as\n\t\t\t\t\tpart of the 2.\n\n\t\t\t\t 5) unuse_mm(), that iterates\n\t\t\t\t\tthrough the vma\u0026apos;s of this \u0026apos;mm\u0026apos;\n\t\t\t\t\twill hit the non-NULL zero entry\n\t\t\t\t\tand operating on this zero entry\n\t\t\t\t\tas a vma is resulting into the\n\t\t\t\t\toops.\n\nThe proper fix would be around not exposing this partially-valid tree to\nothers when droping the mmap lock, which is being solved with [1]. A\nsimpler solution would be checking for MMF_UNSTABLE, as it is set if\nmm_struct is not fully initialized in dup_mmap().\n\nThanks to Liam/Lorenzo/David for all the suggestions in fixing this\nissue.(CVE-2025-39992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix warning in smc_rx_splice() when calling get_page()\n\nsmc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are\nlater passed to get_page() in smc_rx_splice(). Since kmalloc memory is\nnot page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents\nholding a refcount on the buffer. This can lead to use-after-free if\nthe memory is released before splice_to_pipe() completes.\n\nUse folio_alloc() instead, ensuring DMBs are page-backed and safe for\nget_page().\n\nWARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc]\nCPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE\nHardware name: IBM 3931 A01 704 (z/VM 7.4.0)\nKrnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc])\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\nKrnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005\n 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000\n 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000\n 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8\nKrnl Code: 0007931610326960: af000000\t\tmc\t0,0\n 0007931610326964: a7f4ff43\t\tbrc\t15,00079316103267ea\n #0007931610326968: af000000\t\tmc\t0,0\n \u0026gt;000793161032696c: a7f4ff3f\t\tbrc\t15,00079316103267ea\n 0007931610326970: e320f1000004\tlg\t%r2,256(%r15)\n 0007931610326976: c0e53fd1b5f5\tbrasl\t%r14,000793168fd5d560\n 000793161032697c: a7f4fbb5\t\tbrc\t15,00079316103260e6\n 0007931610326980: b904002b\t\tlgr\t%r2,%r11\nCall Trace:\n smc_rx_splice+0xafc/0xe20 [smc]\n smc_rx_splice+0x756/0xe20 [smc])\n smc_rx_recvmsg+0xa74/0xe00 [smc]\n smc_splice_read+0x1ce/0x3b0 [smc]\n sock_splice_read+0xa2/0xf0\n do_splice_read+0x198/0x240\n splice_file_to_pipe+0x7e/0x110\n do_splice+0x59e/0xde0\n __do_splice+0x11a/0x2d0\n __s390x_sys_splice+0x140/0x1f0\n __do_syscall+0x122/0x280\n system_call+0x6e/0x90\nLast Breaking-Event-Address:\nsmc_rx_splice+0x960/0xe20 [smc]\n---[ end trace 0000000000000000 ]---(CVE-2025-40012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak\n\nStruct ff_effect_compat is embedded twice inside\nuinput_ff_upload_compat, contains internal padding. In particular, there\nis a hole after struct ff_replay to satisfy alignment requirements for\nthe following union member. Without clearing the structure,\ncopy_to_user() may leak stack data to userspace.\n\nInitialize ff_up_compat to zero before filling valid fields.(CVE-2025-40035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: nci: Add parameter validation for packet data\n\nSyzbot reported an uninitialized value bug in nci_init_req, which was\nintroduced by commit 5aca7966d2a7 (\u0026quot;Merge tag\n\u0026apos;perf-tools-fixes-for-v6.17-2025-09-16\u0026apos; of\ngit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools\u0026quot;).\n\nThis bug arises due to very limited and poor input validation\nthat was done at nic_valid_size(). This validation only\nvalidates the skb-\u0026gt;len (directly reflects size provided at the\nuserspace interface) with the length provided in the buffer\nitself (interpreted as NCI_HEADER). This leads to the processing\nof memory content at the address assuming the correct layout\nper what opcode requires there. This leads to the accesses to\nbuffer of `skb_buff-\u0026gt;data` which is not assigned anything yet.\n\nFollowing the same silent drop of packets of invalid sizes at\n`nic_valid_size()`, add validation of the data in the respective\nhandlers and return error values in case of failure. Release\nthe skb if error values are returned from handlers in\n`nci_nft_packet` and effectively do a silent drop\n\nPossible TODO: because we silently drop the packets, the\ncall to `nci_request` will be waiting for completion of request\nand will face timeouts. These timeouts can get excessively logged\nin the dmesg. A proper handling of them may require to export\n`nci_request_cancel` (or propagate error handling from the\nnft packets handlers).(CVE-2025-40043)\n\nIn the Linux kernel, a race condition vulnerability exists in the uio_hv_generic driver. The driver\u0026apos;s default interrupt mask setting logic is flawed, as the interrupt mask value should be completely controlled by user space. If the mask bit gets changed by the driver concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, causing the user-mode driver to miss an interrupt and leading to a system hang.\n\nSpecifically, when the driver sets the inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. This results in the host putting a message into the ring buffer without interruption. Subsequently, when user space code in the guest sets the inbound ring buffer interrupt mask to 0 and waits for an interrupt via pread(), since there\u0026apos;s already a message in the ring buffer, no new interrupt is generated, causing pread() to wait indefinitely.\n\nThe fix removes all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable user space control of the interrupt mask by writing 0/1 to /dev/uioX.(CVE-2025-40048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dlink: handle copy_thresh allocation failure\n\nThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.\nIf the allocation failed, dereferencing `skb-\u0026gt;protocol` could lead to\na NULL pointer dereference.\n\nThis patch tries to allocate `skb`. If the allocation fails, it falls\nback to the normal path.\n\nTested-on: D-Link DGE-550T Rev-A3(CVE-2025-40053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix double free in user_cluster_connect()\n\nuser_cluster_disconnect() frees \u0026quot;conn-\u0026gt;cc_private\u0026quot; which is \u0026quot;lc\u0026quot; but then\nthe error handling frees \u0026quot;lc\u0026quot; a second time. Set \u0026quot;lc\u0026quot; to NULL on this\npath to avoid a double free.(CVE-2025-40055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nBUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186\nRead of size 2 at addr ffff8880289ef218 by task syz.6.248/14290\n\nCPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x5f0 mm/kasan/report.c:482\n kasan_report+0xca/0x100 mm/kasan/report.c:595\n hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186\n hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738\n vfs_listxattr+0xbe/0x140 fs/xattr.c:493\n listxattr+0xee/0x190 fs/xattr.c:924\n filename_listxattr fs/xattr.c:958 [inline]\n path_listxattrat+0x143/0x360 fs/xattr.c:988\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe0e9fae16d\nCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3\nRAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000\nRBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 14290:\n kasan_save_stack+0x24/0x50 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4333 [inline]\n __kmalloc_noprof+0x219/0x540 mm/slub.c:4345\n kmalloc_noprof include/linux/slab.h:909 [inline]\n hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21\n hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697\n vfs_listxattr+0xbe/0x140 fs/xattr.c:493\n listxattr+0xee/0x190 fs/xattr.c:924\n filename_listxattr fs/xattr.c:958 [inline]\n path_listxattrat+0x143/0x360 fs/xattr.c:988\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWhen hfsplus_uni2asc is called from hfsplus_listxattr,\nit actually passes in a struct hfsplus_attr_unistr*.\nThe size of the corresponding structure is different from that of hfsplus_unistr,\nso the previous fix (94458781aee6) is insufficient.\nThe pointer on the unicode buffer is still going beyond the allocated memory.\n\nThis patch introduces two warpper functions hfsplus_uni2asc_xattr_str and\nhfsplus_uni2asc_str to process two unicode buffers,\nstruct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.\nWhen ustrlen value is bigger than the allocated memory size,\nthe ustrlen value is limited to an safe size.(CVE-2025-40082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: transport_ipc: validate payload size before reading handle\n\nhandle_response() dereferences the payload as a 4-byte handle without\nverifying that the declared payload size is at least 4 bytes. A malformed\nor truncated message from ksmbd.mountd can lead to a 4-byte read past the\ndeclared payload size. Validate the size before dereferencing.\n\nThis is a minimal fix to guard the initial handle read.(CVE-2025-40084)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the hfsplus_strcasecmp() function of the hfsplus filesystem. When the hfsplus_strcasecmp() logic is triggered, it causes a slab-out-of-bounds read, allowing attackers to read sensitive information from kernel memory. This vulnerability triggers KASAN-detected boundary check errors and could be exploited for information disclosure or system crash attacks.(CVE-2025-40088)\n\nIn the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present. Ensure that set_ent is always set since only drbg provides it. The Linux kernel CVE team has assigned CVE-2025-40109 to this issue.(CVE-2025-40109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix a null-ptr access in the cursor snooper\n\nCheck that the resource which is converted to a surface exists before\ntrying to use the cursor snooper on it.\n\nvmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers\nbecause some svga commands accept SVGA3D_INVALID_ID to mean \u0026quot;no surface\u0026quot;,\nunfortunately functions that accept the actual surfaces as objects might\n(and in case of the cursor snooper, do not) be able to handle null\nobjects. Make sure that we validate not only the identifier (via the\nvmw_cmd_res_check) but also check that the actual resource exists before\ntrying to do something with it.\n\nFixes unchecked null-ptr reference in the snooping code.(CVE-2025-40110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock\n\nPrevent USB runtime PM (autosuspend) for AX88772* in bind.\n\nusbnet enables runtime PM (autosuspend) by default, so disabling it via\nthe usb_driver flag is ineffective. On AX88772B, autosuspend shows no\nmeasurable power saving with current driver (no link partner, admin\nup/down). The ~0.453 W -\u0026gt; ~0.248 W drop on v6.1 comes from phylib powering\nthe PHY off on admin-down, not from USB autosuspend.\n\nThe real hazard is that with runtime PM enabled, ndo_open() (under RTNL)\nmay synchronously trigger autoresume (usb_autopm_get_interface()) into\nasix_resume() while the USB PM lock is held. Resume paths then invoke\nphylink/phylib and MDIO, which also expect RTNL, leading to possible\ndeadlocks or PM lock vs MDIO wake issues.\n\nTo avoid this, keep the device runtime-PM active by taking a usage\nreference in ax88772_bind() and dropping it in unbind(). A non-zero PM\nusage count blocks runtime suspend regardless of userspace policy\n(.../power/control - pm_runtime_allow/forbid), making this approach\nrobust against sysfs overrides.\n\nHolding a runtime-PM usage ref does not affect system-wide suspend;\nsystem sleep/resume callbacks continue to run as before.(CVE-2025-40120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Enforce expected_attach_type for tailcall compatibility\n\nYinhao et al. recently reported:\n\n Our fuzzer tool discovered an uninitialized pointer issue in the\n bpf_prog_test_run_xdp() function within the Linux kernel\u0026apos;s BPF subsystem.\n This leads to a NULL pointer dereference when a BPF program attempts to\n deference the txq member of struct xdp_buff object.\n\nThe test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the\nentry point for bpf_prog_test_run_xdp() and its expected_attach_type can\nneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot\nof a tailcall map it owns. progB\u0026apos;s expected_attach_type must be BPF_XDP_DEVMAP\nto pass xdp_is_valid_access() validation. The program returns struct xdp_md\u0026apos;s\negress_ifindex, and the latter is only allowed to be accessed under mentioned\nexpected_attach_type. progB is then inserted into the tailcall which progA\ncalls.\n\nThe underlying issue goes beyond XDP though. Another example are programs\nof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well\nas sock_addr_func_proto() have different logic depending on the programs\u0026apos;\nexpected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME\nshould not be allowed doing a tailcall into a program which calls bpf_bind()\nout of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.\n\nIn short, specifying expected_attach_type allows to open up additional\nfunctionality or restrictions beyond what the basic bpf_prog_type enables.\nThe use of tailcalls must not violate these constraints. Fix it by enforcing\nexpected_attach_type in __bpf_prog_map_compatible().\n\nNote that we only enforce this for tailcall maps, but not for BPF devmaps or\ncpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and\ncpu_map_bpf_prog_run*() which set up a new environment / context and therefore\nthese situations are not prone to this issue.(CVE-2025-40123)\n\nIn the Linux kernel, a vulnerability exists in the blk-mq component: the return value of blk_mq_sysfs_register_hctxs() is not checked in __blk_mq_update_nr_hw_queues() function. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger kernel warnings. The issue occurs because kobject_del() is called unconditionally even when sysfs creation fails, leading to kernfs directory operation errors.(CVE-2025-40125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix null pointer dereference on zero-length checksum\n\nIn xdr_stream_decode_opaque_auth(), zero-length checksum.len causes\nchecksum.data to be set to NULL. This triggers a NPD when accessing\nchecksum.data in gss_krb5_verify_mic_v2(). This patch ensures that\nthe value of checksum.len is not less than XDR_UNIT.(CVE-2025-40129)\n\nIn the Linux kernel, there is a race condition between device manager (dm) suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes, causing q-\u0026gt;tag_set to be a NULL pointer and leading to system crash. The vulnerability affects Linux kernel versions from 5.0 to 6.17.2.(CVE-2025-40134)\n\nIn the Linux kernel, a race condition vulnerability exists in the rtl8150 USB network driver\u0026apos;s rtl8150_set_multicast function. The vulnerability occurs because rtl8150_set_multicast incorrectly calls netif_stop_queue and netif_wake_queue, causing TX queue synchronization issues. When rtl8150_set_multicast wakes up the TX queue before USB transfer completion, it may lead to double submission of URB in rtl8150_start_xmit, resulting in warnings and potential system instability.(CVE-2025-40140)\n\nIn the Linux kernel, a use-after-free vulnerability has been identified in the Bluetooth ISO module. This vulnerability is similar to the issue in sco_conn_free where if conn-\u0026gt;sk is not set to NULL, it may lead to use-after-free in iso_conn_free.(CVE-2025-40141)\n\nA vulnerability was found in the Linux kernel where calling mprotect() on large hugetlb memory areas (approximately 300GB) can cause soft lockup issues. The CPU becomes stuck for extended periods, making the system unresponsive. This occurs because the hugetlb handling for large memory lacks proper scheduling opportunities, unlike THP or base pages which already have cond_resched() calls. Although the soft lockup was triggered by MTE, this is not MTE-specific - any processing that takes a long time in the loop may trigger soft lockup.(CVE-2025-40153)\n\nIn the Linux kernel, the usbnet driver contains a stack-based buffer overflow vulnerability. Syzbot reported warnings about using smp_processor_id() in preemptible code. This vulnerability may lead to stack buffer overflow, affecting system confidentiality, integrity, and availability. The vulnerability stems from the incorrect use of smp_processor_id() function in the usbnet_skb_return function within preemptible context.(CVE-2025-40164)\n\nIn the Linux kernel, a vulnerability has been found in the ext4 filesystem. When opening a verity file on a corrupted ext4 filesystem mounted without a journal, syzbot reported a BUG_ON in ext4_es_cache_extent(). The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set. This is an invalid combination since an inode should have either: INLINE_DATA (data stored directly in the inode) or EXTENTS (data stored in extent-mapped blocks). Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes.(CVE-2025-40167)\n\nIn the Linux kernel, the check_alu_op() function in the BPF verifier contains a vulnerability when validating ALU operation instructions. The function validates BPF program instructions where the \u0026apos;offset\u0026apos; field is a signed 16-bit integer. The original check condition \u0026apos;insn-\u0026gt;off \u0026gt; 1\u0026apos; was intended to ensure the offset is either 0 or 1 (for BPF_MOD/BPF_DIV operations). However, since \u0026apos;insn-\u0026gt;off\u0026apos; is signed, this check incorrectly accepts all negative values (e.g., -1). This vulnerability allows maliciously crafted BPF programs to bypass verification, potentially leading to privilege escalation and other security issues.(CVE-2025-40169)\n\nIn the Linux kernel, a vulnerability has been found in the nvmet-fc module. When multiple async commands are in flight from __nvmet_fc_send_ls_req, a tgtport reference is taken for each command. In the current code, only one put work item is queued at a time, which results in a leaked reference. This vulnerability affects multiple Linux kernel version branches.(CVE-2025-40171)\n\nIn the Linux kernel, a vulnerability has been identified in the net/ip6_tunnel module. Similar to IPv4 tunnel, IPv6 version also updates dev-\u0026gt;needed_headroom. While IPv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd, the IPv6 tunnel continues to increase headroom without any ceiling. This vulnerability may lead to perpetual tunnel growth, affecting system confidentiality, integrity, and availability, with potential privilege escalation risks.(CVE-2025-40173)\n\nIn the Linux kernel, during asynchronous decryption in the TLS module, the tls_strp_msg_hold function is called to create a clone of the input skb to hold references to the memory it uses. If the allocation of this clone fails, proceeding with asynchronous decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, the system should wait for all pending decryption requests to complete.(CVE-2025-40176)\n\nIn the Linux kernel, there is a NULL pointer dereference vulnerability in the pid_nr_ns function. When task_active_pid_ns returns null, it triggers kernel panic. The vulnerability manifests as kernel panic when task_active_pid_ns returns null in the pid_nr_ns function. The vulnerability example shows inability to handle kernel NULL pointer dereference errors, leading to system crash. The specific error is \u0026apos;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058\u0026apos;, ultimately causing kernel panic and system crash.(CVE-2025-40178)\n\nIn the Linux kernel, the ext4 filesystem has a vulnerability: orphan files can be arbitrarily large in principle. However, orphan replay needs to traverse all content and pin all buffers in memory. Filesystems with absurdly large orphan files can lead to significant memory consumption. The vulnerability limits orphan file size to a sane value and uses kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for large orphan files.(CVE-2025-40179)\n\nIn the Linux kernel, a memory leak vulnerability exists. Cilium\u0026apos;s BPF egress gateway feature redirects K8s Pod traffic through vxlan tunnels to dedicated egress gateways. When using the bpf_redirect_neigh() helper to forward packets, vxlan allocates metadata_dst objects and attaches them to skb through fake dst entries. However, since bpf_redirect_neigh() only sets new dst entries without first dropping existing ones, the metadata_dst objects are never released, causing continuous increase in kmalloc-256 slab usage.(CVE-2025-40183)\n\nIn the Linux kernel, a NULL pointer dereference vulnerability exists in the SCTP protocol. When new_asoc-\u0026gt;peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0, and sctp_ulpevent_make_authkey() returns 0, the variable ai_ev remains zero and this zero value will be dereferenced in the sctp_ulpevent_free() function.(CVE-2025-40187)\n\nIn the Linux kernel, there is a reference count underflow vulnerability in the ext4 file system. Syzkaller discovered a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already \u0026lt;= 0 and then applies ref_change (often -1), causing the refcount to underflow and proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow, EXT4-fs warning: ea_inode dec ref err. The fix makes the invariant explicit: if the current refcount is non-positive, treat it as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount.(CVE-2025-40190)\n\nIn the Linux kernel, the following vulnerability has been resolved: Revert \u0026quot;ipmi: fix msg stack when IPMI is disconnected\u0026quot;. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.(CVE-2025-40192)\n\nIn the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request(). The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.(CVE-2025-40194)\n\nIn the Linux kernel, a buffer over-read vulnerability has been discovered in the parse_apply_sb_mount_options() function of the ext4 filesystem. Unlike other strings in the ext4 superblock, this vulnerability relies on tune2fs to ensure s_mount_opts is NUL terminated. The parse_apply_sb_mount_options() function has been hardened by treating s_mount_opts as a potential __nonstring.(CVE-2025-40198)\n\nIn the Linux kernel, a vulnerability has been identified in the Squashfs filesystem\u0026apos;s squashfs_read_inode() function, which fails to properly validate input data and may accept negative file sizes. Syskaller reports a \u0026quot;WARNING in ovl_copy_up_file\u0026quot; in overlayfs. This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size. This commit fixes the issue by checking for negative file sizes and returning EINVAL.(CVE-2025-40200)\n\nIn the Linux kernel, the sys_prlimit64() path has a race condition issue with the usage of task_lock(tsk-\u0026gt;group_leader). When tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk-\u0026gt;group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes -\u0026gt;group_leader. In this case do_prlimit() may take the wrong lock, or (worse) -\u0026gt;group_leader may change between task_lock() and task_unlock(). The fix changes sys_prlimit64() to take tasklist_lock when necessary.(CVE-2025-40201)\n\nIn the Linux kernel, the IPMI subsystem\u0026apos;s user message limit handling had a number of issues, including improper counting in some cases and a use-after-free vulnerability. The vulnerability has been resolved by restructuring the handling to manage more in the receive message allocation routine, where all referencing and user message limit counts are now handled, making the process cleaner and safer. This vulnerability affects Linux Kernel versions from 5.19 to 6.18-rc1.(CVE-2025-40202)\n\nIn the Linux kernel, the SCTP protocol\u0026apos;s MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)\n\nIn the Linux kernel, the netfilter nft_objref module has a validation bypass vulnerability. Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls. This vulnerability allows attackers to trigger kernel stack overflow through specially crafted nftables rules, leading to system crash. Validation functions for objref and objrefmap expressions have been implemented, currently only NFT_OBJECT_SYNPROXY object type requires validation.(CVE-2025-40206)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the ACPI video subsystem. The switch_brightness_work delayed work accesses device-\u0026gt;brightness and device-\u0026gt;backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device-\u0026gt;brightness or device-\u0026gt;backlight. The issue is fixed by calling cancel_delayed_work_sync() for each device\u0026apos;s switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work, ensuring the work completes before the memory is freed.(CVE-2025-40211)",
"id": "OESA-2025-2765",
"modified": "2026-08-06T11:09:53Z",
"published": "2025-11-28T11:09:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2765"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36357"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38100"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38581"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38717"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39692"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39694"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39703"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39751"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39940"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39964"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40109"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40110"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40134"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40140"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40164"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40167"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40169"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40183"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40187"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40200"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40204"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40211"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-36357",
"CVE-2025-22080",
"CVE-2025-23150",
"CVE-2025-37785",
"CVE-2025-37828",
"CVE-2025-38011",
"CVE-2025-38084",
"CVE-2025-38100",
"CVE-2025-38173",
"CVE-2025-38214",
"CVE-2025-38581",
"CVE-2025-38705",
"CVE-2025-38717",
"CVE-2025-38729",
"CVE-2025-39692",
"CVE-2025-39694",
"CVE-2025-39703",
"CVE-2025-39751",
"CVE-2025-39931",
"CVE-2025-39938",
"CVE-2025-39940",
"CVE-2025-39964",
"CVE-2025-39992",
"CVE-2025-40012",
"CVE-2025-40035",
"CVE-2025-40043",
"CVE-2025-40048",
"CVE-2025-40053",
"CVE-2025-40055",
"CVE-2025-40082",
"CVE-2025-40084",
"CVE-2025-40088",
"CVE-2025-40109",
"CVE-2025-40110",
"CVE-2025-40120",
"CVE-2025-40123",
"CVE-2025-40125",
"CVE-2025-40129",
"CVE-2025-40134",
"CVE-2025-40140",
"CVE-2025-40141",
"CVE-2025-40153",
"CVE-2025-40164",
"CVE-2025-40167",
"CVE-2025-40169",
"CVE-2025-40171",
"CVE-2025-40173",
"CVE-2025-40176",
"CVE-2025-40178",
"CVE-2025-40179",
"CVE-2025-40183",
"CVE-2025-40187",
"CVE-2025-40190",
"CVE-2025-40192",
"CVE-2025-40194",
"CVE-2025-40198",
"CVE-2025-40200",
"CVE-2025-40201",
"CVE-2025-40202",
"CVE-2025-40204",
"CVE-2025-40206",
"CVE-2025-40211"
]
}
OESA-2025-2766 (CVE-2024-36357)
Vulnerability from osv_openeuler – Published: 2025-11-28 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
A transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357)
In the Linux kernel, the following vulnerability has been resolved:
cdx: Fix possible UAF error in driver_override_show()
Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c
This function driver_override_show() is part of DEVICE_ATTR_RW, which includes both driver_override_show() and driver_override_store(). These functions can be executed concurrently in sysfs.
The driver_override_store() function uses driver_set_override() to update the driver_override value, and driver_set_override() internally locks the device (device_lock(dev)). If driver_override_show() reads cdx_dev->driver_override without locking, it could potentially access a freed pointer if driver_override_store() frees the string concurrently. This could lead to printing a kernel address, which is a security risk since DEVICE_ATTR can be read by all users.
Additionally, a similar pattern is used in drivers/amba/bus.c, as well as many other bus drivers, where device_lock() is taken in the show function, and it has been working without issues.
This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations.(CVE-2025-21915)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Prevent integer overflow in hdr_first_de()
The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow.(CVE-2025-22080)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()
A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash.
Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed.
This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue").
This is found by our static analysis tool KNighter.(CVE-2025-37828)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: unshare page tables during VMA split, not before
Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split.
Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked.
An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts:
- from hugetlb_split(), holding:
- mmap lock (exclusively)
- VMA lock
- file rmap lock (exclusively)
- hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock
Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back.
[(CVE-2025-38084)
In the Linux kernel, the following vulnerability has been resolved:
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork().
io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference.
There are two issues, which lead to that problem:
1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork().
2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated.
This happens when a kernel thread is created in the context of
a user space thread, which has TIF_IO_BITMAP set as the thread
flags are copied and the IO bitmap pointer is cleared.
Other than in the failed fork() case this has no impact because
kernel threads including IO workers never return to user space and
therefore never invoke tss_update_io_bitmap().
Cure this by adding the missing cleanups and checks:
1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task.
2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().
For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state.(CVE-2025-38100)
In the Linux kernel, the following vulnerability has been resolved:
crypto: marvell/cesa - Handle zero-length skcipher requests
Do not access random memory for zero-length skcipher requests. Just return 0.(CVE-2025-38173)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var
If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var.
================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================
The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38214)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix crash when rebind ccp device for ccp.ko
When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash:
$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind
[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device.
Tested on AMD Ryzen 7 1700X.(CVE-2025-38581)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix null pointer access
Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.(CVE-2025-38705)
In the Linux kernel, the following vulnerability has been resolved:
net: kcm: Fix race condition in kcm_unattach()
syzbot found a race condition when kcm_unattach(psock) and kcm_release(kcm) are executed at the same time.
kcm_unattach() is missing a check of the flag kcm->tx_stopped before calling queue_work().
If the kcm has a reserved psock, kcm_unattach() might get executed between cancel_work_sync() and unreserve_psock() in kcm_release(), requeuing kcm->tx_work right before kcm gets freed in kcm_done().
Remove kcm->tx_stopped and replace it by the less error-prone disable_work_sync().(CVE-2025-38717)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
In the Linux kernel, the following vulnerability has been resolved:
smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()
We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()!
Otherwise already existing connections try to use smb_direct_wq as a NULL pointer.(CVE-2025-39692)
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Fix SCCB present check
Tracing code called by the SCLP interrupt handler contains early exits if the SCCB address associated with an interrupt is NULL. This check is performed after physical to virtual address translation.
If the kernel identity mapping does not start at address zero, the resulting virtual address is never zero, so that the NULL checks won't work. Subsequently this may result in incorrect accesses to the first page of the identity mapping.
Fix this by introducing a function that handles the NULL case before address translation.(CVE-2025-39694)
In the Linux kernel, the following vulnerability has been resolved:
net, hsr: reject HSR frame if skb can't hold tag
Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG):
[ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0
<snip registers, remove unreliable trace>
[ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skb_push+0xcd/0xf0 [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0 [ 45.406513] br_forward_finish+0x128/0x260 [ 45.408483] __br_forward+0x42d/0x590 [ 45.409464] maybe_deliver+0x2eb/0x420 [ 45.409763] br_flood+0x174/0x4a0 [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0 [ 45.411618] br_handle_frame+0xac3/0x1230 [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0 [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0 [ 45.424478] __netif_receive_skb+0x22/0x170 [ 45.424806] process_backlog+0x242/0x6d0 [ 45.425116] __napi_poll+0xbb/0x630 [ 45.425394] net_rx_action+0x4d1/0xcc0 [ 45.427613] handle_softirqs+0x1a4/0x580 [ 45.427926] do_softirq+0x74/0x90 [ 45.428196] </IRQ>
This issue was found by syzkaller.
The panic happens in br_dev_queue_push_xmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skb_push() call, there's not enough headroom and skb_push() panics.
The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG).
Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers.
Alternative fix would be to check for enough headroom before skb_push() in br_dev_queue_push_xmit().
In the reproducer, this is injected via AF_PACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network.
Further Details:
In the reproducer, the following network interface chain is set up:
┌────────────────┐ ┌────────────────┐ │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘
To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---(CVE-2025-39703)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39751)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Set merge to zero early in af_alg_sendmsg
If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done.
Fix this by setting ctx->merge to zero near the start of the loop.(CVE-2025-39931)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed
If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and "dai_data->graph[dai->id]" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception:
qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0(CVE-2025-39938)
In the Linux kernel, the following vulnerability has been resolved:
dm-stripe: fix a possible integer overflow
There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;(CVE-2025-39940)
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg
Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state.
Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing.(CVE-2025-39964)
In the Linux kernel, the following vulnerability has been resolved:
mm: swap: check for stable address space before operating on the VMA
It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault
The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup().
2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation.
3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap().
4) swapoff is tried on the
'mm' added to the 'mmlist' as
part of the 2.
5) unuse_mm(), that iterates
through the vma's of this 'mm'
will hit the non-NULL zero entry
and operating on this zero entry
as a vma is resulting into the
oops.
The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap().
Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.(CVE-2025-39992)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix warning in smc_rx_splice() when calling get_page()
smc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are later passed to get_page() in smc_rx_splice(). Since kmalloc memory is not page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents holding a refcount on the buffer. This can lead to use-after-free if the memory is released before splice_to_pipe() completes.
Use folio_alloc() instead, ensuring DMBs are page-backed and safe for get_page().
WARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc] CPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE Hardware name: IBM 3931 A01 704 (z/VM 7.4.0) Krnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8 Krnl Code: 0007931610326960: af000000 mc 0,0 0007931610326964: a7f4ff43 brc 15,00079316103267ea #0007931610326968: af000000 mc 0,0 >000793161032696c: a7f4ff3f brc 15,00079316103267ea 0007931610326970: e320f1000004 lg %r2,256(%r15) 0007931610326976: c0e53fd1b5f5 brasl %r14,000793168fd5d560 000793161032697c: a7f4fbb5 brc 15,00079316103260e6 0007931610326980: b904002b lgr %r2,%r11 Call Trace: smc_rx_splice+0xafc/0xe20 [smc] smc_rx_splice+0x756/0xe20 [smc]) smc_rx_recvmsg+0xa74/0xe00 [smc] smc_splice_read+0x1ce/0x3b0 [smc] sock_splice_read+0xa2/0xf0 do_splice_read+0x198/0x240 splice_file_to_pipe+0x7e/0x110 do_splice+0x59e/0xde0 __do_splice+0x11a/0x2d0 __s390x_sys_splice+0x140/0x1f0 __do_syscall+0x122/0x280 system_call+0x6e/0x90 Last Breaking-Event-Address: smc_rx_splice+0x960/0xe20 [smc] ---[ end trace 0000000000000000 ]---(CVE-2025-40012)
In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak
Struct ff_effect_compat is embedded twice inside uinput_ff_upload_compat, contains internal padding. In particular, there is a hole after struct ff_replay to satisfy alignment requirements for the following union member. Without clearing the structure, copy_to_user() may leak stack data to userspace.
Initialize ff_up_compat to zero before filling valid fields.(CVE-2025-40035)
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: nci: Add parameter validation for packet data
Syzbot reported an uninitialized value bug in nci_init_req, which was introduced by commit 5aca7966d2a7 ("Merge tag 'perf-tools-fixes-for-v6.17-2025-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").
This bug arises due to very limited and poor input validation
that was done at nic_valid_size(). This validation only
validates the skb->len (directly reflects size provided at the
userspace interface) with the length provided in the buffer
itself (interpreted as NCI_HEADER). This leads to the processing
of memory content at the address assuming the correct layout
per what opcode requires there. This leads to the accesses to
buffer of skb_buff->data which is not assigned anything yet.
Following the same silent drop of packets of invalid sizes at
nic_valid_size(), add validation of the data in the respective
handlers and return error values in case of failure. Release
the skb if error values are returned from handlers in
nci_nft_packet and effectively do a silent drop
Possible TODO: because we silently drop the packets, the
call to nci_request will be waiting for completion of request
and will face timeouts. These timeouts can get excessively logged
in the dmesg. A proper handling of them may require to export
nci_request_cancel (or propagate error handling from the
nft packets handlers).(CVE-2025-40043)
In the Linux kernel, a race condition vulnerability exists in the uio_hv_generic driver. The driver's default interrupt mask setting logic is flawed, as the interrupt mask value should be completely controlled by user space. If the mask bit gets changed by the driver concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, causing the user-mode driver to miss an interrupt and leading to a system hang.
Specifically, when the driver sets the inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. This results in the host putting a message into the ring buffer without interruption. Subsequently, when user space code in the guest sets the inbound ring buffer interrupt mask to 0 and waits for an interrupt via pread(), since there's already a message in the ring buffer, no new interrupt is generated, causing pread() to wait indefinitely.
The fix removes all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable user space control of the interrupt mask by writing 0/1 to /dev/uioX.(CVE-2025-40048)
In the Linux kernel, the following vulnerability has been resolved:
net: dlink: handle copy_thresh allocation failure
The driver did not handle failure of netdev_alloc_skb_ip_align().
If the allocation failed, dereferencing skb->protocol could lead to
a NULL pointer dereference.
This patch tries to allocate skb. If the allocation fails, it falls
back to the normal path.
Tested-on: D-Link DGE-550T Rev-A3(CVE-2025-40053)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix double free in user_cluster_connect()
user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free.(CVE-2025-40055)
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290
CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x5f0 mm/kasan/report.c:482 kasan_report+0xca/0x100 mm/kasan/report.c:595 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe0e9fae16d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3 RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000 RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000 </TASK>
Allocated by task 14290: kasan_save_stack+0x24/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4333 [inline] __kmalloc_noprof+0x219/0x540 mm/slub.c:4345 kmalloc_noprof include/linux/slab.h:909 [inline] hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697 vfs_listxattr+0xbe/0x140 fs/xattr.c:493 listxattr+0xee/0x190 fs/xattr.c:924 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x143/0x360 fs/xattr.c:988 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
When hfsplus_uni2asc is called from hfsplus_listxattr, it actually passes in a struct hfsplus_attr_unistr*. The size of the corresponding structure is different from that of hfsplus_unistr, so the previous fix (94458781aee6) is insufficient. The pointer on the unicode buffer is still going beyond the allocated memory.
This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and hfsplus_uni2asc_str to process two unicode buffers, struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively. When ustrlen value is bigger than the allocated memory size, the ustrlen value is limited to an safe size.(CVE-2025-40082)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: transport_ipc: validate payload size before reading handle
handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing.
This is a minimal fix to guard the initial handle read.(CVE-2025-40084)
In the Linux kernel, a buffer overflow vulnerability exists in the hfsplus_strcasecmp() function of the hfsplus filesystem. When the hfsplus_strcasecmp() logic is triggered, it causes a slab-out-of-bounds read, allowing attackers to read sensitive information from kernel memory. This vulnerability triggers KASAN-detected boundary check errors and could be exploited for information disclosure or system crash attacks.(CVE-2025-40088)
In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present. Ensure that set_ent is always set since only drbg provides it. The Linux kernel CVE team has assigned CVE-2025-40109 to this issue.(CVE-2025-40109)
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix a null-ptr access in the cursor snooper
Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it.
vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean "no surface", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it.
Fixes unchecked null-ptr reference in the snooping code.(CVE-2025-40110)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock
Prevent USB runtime PM (autosuspend) for AX88772* in bind.
usbnet enables runtime PM (autosuspend) by default, so disabling it via the usb_driver flag is ineffective. On AX88772B, autosuspend shows no measurable power saving with current driver (no link partner, admin up/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering the PHY off on admin-down, not from USB autosuspend.
The real hazard is that with runtime PM enabled, ndo_open() (under RTNL) may synchronously trigger autoresume (usb_autopm_get_interface()) into asix_resume() while the USB PM lock is held. Resume paths then invoke phylink/phylib and MDIO, which also expect RTNL, leading to possible deadlocks or PM lock vs MDIO wake issues.
To avoid this, keep the device runtime-PM active by taking a usage reference in ax88772_bind() and dropping it in unbind(). A non-zero PM usage count blocks runtime suspend regardless of userspace policy (.../power/control - pm_runtime_allow/forbid), making this approach robust against sysfs overrides.
Holding a runtime-PM usage ref does not affect system-wide suspend; system sleep/resume callbacks continue to run as before.(CVE-2025-40120)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Enforce expected_attach_type for tailcall compatibility
Yinhao et al. recently reported:
Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.
The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls.
The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.
In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible().
Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run() and cpu_map_bpf_prog_run() which set up a new environment / context and therefore these situations are not prone to this issue.(CVE-2025-40123)
In the Linux kernel, a vulnerability exists in the blk-mq component: the return value of blk_mq_sysfs_register_hctxs() is not checked in __blk_mq_update_nr_hw_queues() function. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger kernel warnings. The issue occurs because kobject_del() is called unconditionally even when sysfs creation fails, leading to kernfs directory operation errors.(CVE-2025-40125)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix null pointer dereference on zero-length checksum
In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes checksum.data to be set to NULL. This triggers a NPD when accessing checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that the value of checksum.len is not less than XDR_UNIT.(CVE-2025-40129)
In the Linux kernel, there is a race condition between device manager (dm) suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes, causing q->tag_set to be a NULL pointer and leading to system crash. The vulnerability affects Linux kernel versions from 5.0 to 6.17.2.(CVE-2025-40134)
In the Linux kernel, a race condition vulnerability exists in the rtl8150 USB network driver's rtl8150_set_multicast function. The vulnerability occurs because rtl8150_set_multicast incorrectly calls netif_stop_queue and netif_wake_queue, causing TX queue synchronization issues. When rtl8150_set_multicast wakes up the TX queue before USB transfer completion, it may lead to double submission of URB in rtl8150_start_xmit, resulting in warnings and potential system instability.(CVE-2025-40140)
In the Linux kernel, a use-after-free vulnerability has been identified in the Bluetooth ISO module. This vulnerability is similar to the issue in sco_conn_free where if conn->sk is not set to NULL, it may lead to use-after-free in iso_conn_free.(CVE-2025-40141)
A vulnerability was found in the Linux kernel where calling mprotect() on large hugetlb memory areas (approximately 300GB) can cause soft lockup issues. The CPU becomes stuck for extended periods, making the system unresponsive. This occurs because the hugetlb handling for large memory lacks proper scheduling opportunities, unlike THP or base pages which already have cond_resched() calls. Although the soft lockup was triggered by MTE, this is not MTE-specific - any processing that takes a long time in the loop may trigger soft lockup.(CVE-2025-40153)
In the Linux kernel, the usbnet driver contains a stack-based buffer overflow vulnerability. Syzbot reported warnings about using smp_processor_id() in preemptible code. This vulnerability may lead to stack buffer overflow, affecting system confidentiality, integrity, and availability. The vulnerability stems from the incorrect use of smp_processor_id() function in the usbnet_skb_return function within preemptible context.(CVE-2025-40164)
In the Linux kernel, a vulnerability has been found in the ext4 filesystem. When opening a verity file on a corrupted ext4 filesystem mounted without a journal, syzbot reported a BUG_ON in ext4_es_cache_extent(). The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set. This is an invalid combination since an inode should have either: INLINE_DATA (data stored directly in the inode) or EXTENTS (data stored in extent-mapped blocks). Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes.(CVE-2025-40167)
In the Linux kernel, the check_alu_op() function in the BPF verifier contains a vulnerability when validating ALU operation instructions. The function validates BPF program instructions where the 'offset' field is a signed 16-bit integer. The original check condition 'insn->off > 1' was intended to ensure the offset is either 0 or 1 (for BPF_MOD/BPF_DIV operations). However, since 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This vulnerability allows maliciously crafted BPF programs to bypass verification, potentially leading to privilege escalation and other security issues.(CVE-2025-40169)
In the Linux kernel, a vulnerability has been found in the nvmet-fc module. When multiple async commands are in flight from __nvmet_fc_send_ls_req, a tgtport reference is taken for each command. In the current code, only one put work item is queued at a time, which results in a leaked reference. This vulnerability affects multiple Linux kernel version branches.(CVE-2025-40171)
In the Linux kernel, a vulnerability has been identified in the net/ip6_tunnel module. Similar to IPv4 tunnel, IPv6 version also updates dev->needed_headroom. While IPv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd, the IPv6 tunnel continues to increase headroom without any ceiling. This vulnerability may lead to perpetual tunnel growth, affecting system confidentiality, integrity, and availability, with potential privilege escalation risks.(CVE-2025-40173)
In the Linux kernel, during asynchronous decryption in the TLS module, the tls_strp_msg_hold function is called to create a clone of the input skb to hold references to the memory it uses. If the allocation of this clone fails, proceeding with asynchronous decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, the system should wait for all pending decryption requests to complete.(CVE-2025-40176)
In the Linux kernel, there is a NULL pointer dereference vulnerability in the pid_nr_ns function. When task_active_pid_ns returns null, it triggers kernel panic. The vulnerability manifests as kernel panic when task_active_pid_ns returns null in the pid_nr_ns function. The vulnerability example shows inability to handle kernel NULL pointer dereference errors, leading to system crash. The specific error is 'Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058', ultimately causing kernel panic and system crash.(CVE-2025-40178)
In the Linux kernel, the ext4 filesystem has a vulnerability: orphan files can be arbitrarily large in principle. However, orphan replay needs to traverse all content and pin all buffers in memory. Filesystems with absurdly large orphan files can lead to significant memory consumption. The vulnerability limits orphan file size to a sane value and uses kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for large orphan files.(CVE-2025-40179)
In the Linux kernel, a memory leak vulnerability exists. Cilium's BPF egress gateway feature redirects K8s Pod traffic through vxlan tunnels to dedicated egress gateways. When using the bpf_redirect_neigh() helper to forward packets, vxlan allocates metadata_dst objects and attaches them to skb through fake dst entries. However, since bpf_redirect_neigh() only sets new dst entries without first dropping existing ones, the metadata_dst objects are never released, causing continuous increase in kmalloc-256 slab usage.(CVE-2025-40183)
In the Linux kernel, a NULL pointer dereference vulnerability exists in the SCTP protocol. When new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0, and sctp_ulpevent_make_authkey() returns 0, the variable ai_ev remains zero and this zero value will be dereferenced in the sctp_ulpevent_free() function.(CVE-2025-40187)
In the Linux kernel, there is a reference count underflow vulnerability in the ext4 file system. Syzkaller discovered a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1), causing the refcount to underflow and proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow, EXT4-fs warning: ea_inode dec ref err. The fix makes the invariant explicit: if the current refcount is non-positive, treat it as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount.(CVE-2025-40190)
In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected". This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.(CVE-2025-40192)
In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request(). The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.(CVE-2025-40194)
In the Linux kernel, a buffer over-read vulnerability has been discovered in the parse_apply_sb_mount_options() function of the ext4 filesystem. Unlike other strings in the ext4 superblock, this vulnerability relies on tune2fs to ensure s_mount_opts is NUL terminated. The parse_apply_sb_mount_options() function has been hardened by treating s_mount_opts as a potential __nonstring.(CVE-2025-40198)
In the Linux kernel, a vulnerability has been identified in the Squashfs filesystem's squashfs_read_inode() function, which fails to properly validate input data and may accept negative file sizes. Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size. This commit fixes the issue by checking for negative file sizes and returning EINVAL.(CVE-2025-40200)
In the Linux kernel, the sys_prlimit64() path has a race condition issue with the usage of task_lock(tsk->group_leader). When tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). The fix changes sys_prlimit64() to take tasklist_lock when necessary.(CVE-2025-40201)
In the Linux kernel, the IPMI subsystem's user message limit handling had a number of issues, including improper counting in some cases and a use-after-free vulnerability. The vulnerability has been resolved by restructuring the handling to manage more in the receive message allocation routine, where all referencing and user message limit counts are now handled, making the process cleaner and safer. This vulnerability affects Linux Kernel versions from 5.19 to 6.18-rc1.(CVE-2025-40202)
In the Linux kernel, the SCTP protocol's MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)
In the Linux kernel, the netfilter nft_objref module has a validation bypass vulnerability. Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls. This vulnerability allows attackers to trigger kernel stack overflow through specially crafted nftables rules, leading to system crash. Validation functions for objref and objrefmap expressions have been implemented, currently only NFT_OBJECT_SYNPROXY object type requires validation.(CVE-2025-40206)
In the Linux kernel, a use-after-free vulnerability exists in the ACPI video subsystem. The switch_brightness_work delayed work accesses device->brightness and device->backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. The issue is fixed by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work, ensuring the work completes before the memory is freed.(CVE-2025-40211)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"perf-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-121.0.0.123.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"perf-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-121.0.0.123.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-121.0.0.123.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nA transient execution vulnerability in some AMD processors may allow an attacker to infer data in the L1D cache, potentially resulting in the leakage of sensitive information across privileged boundaries.(CVE-2024-36357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncdx: Fix possible UAF error in driver_override_show()\n\nFixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c\n\nThis function driver_override_show() is part of DEVICE_ATTR_RW, which\nincludes both driver_override_show() and driver_override_store().\nThese functions can be executed concurrently in sysfs.\n\nThe driver_override_store() function uses driver_set_override() to\nupdate the driver_override value, and driver_set_override() internally\nlocks the device (device_lock(dev)). If driver_override_show() reads\ncdx_dev-\u0026gt;driver_override without locking, it could potentially access\na freed pointer if driver_override_store() frees the string\nconcurrently. This could lead to printing a kernel address, which is a\nsecurity risk since DEVICE_ATTR can be read by all users.\n\nAdditionally, a similar pattern is used in drivers/amba/bus.c, as well\nas many other bus drivers, where device_lock() is taken in the show\nfunction, and it has been working without issues.\n\nThis potential bug was detected by our experimental static analysis\ntool, which analyzes locking APIs and paired functions to identify\ndata races and atomicity violations.(CVE-2025-21915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Prevent integer overflow in hdr_first_de()\n\nThe \u0026quot;de_off\u0026quot; and \u0026quot;used\u0026quot; variables come from the disk so they both need to\ncheck. The problem is that on 32bit systems if they\u0026apos;re both greater than\nUINT_MAX - 16 then the check does work as intended because of an integer\noverflow.(CVE-2025-22080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()\n\nA race can occur between the MCQ completion path and the abort handler:\nonce a request completes, __blk_mq_free_request() sets rq-\u0026gt;mq_hctx to\nNULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in\nufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is\ndereferenced, the kernel will crash.\n\nAdd a NULL check for the returned hwq pointer. If hwq is NULL, log an\nerror and return FAILED, preventing a potential NULL-pointer\ndereference. As suggested by Bart, the ufshcd_cmd_inflight() check is\nremoved.\n\nThis is similar to the fix in commit 74736103fb41 (\u0026quot;scsi: ufs: core: Fix\nufshcd_abort_one racing issue\u0026quot;).\n\nThis is found by our static analysis tool KNighter.(CVE-2025-37828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: unshare page tables during VMA split, not before\n\nCurrently, __split_vma() triggers hugetlb page table unsharing through\nvm_ops-\u0026gt;may_split(). This happens before the VMA lock and rmap locks are\ntaken - which is too early, it allows racing VMA-locked page faults in our\nprocess and racing rmap walks from other processes to cause page tables to\nbe shared again before we actually perform the split.\n\nFix it by explicitly calling into the hugetlb unshare logic from\n__split_vma() in the same place where THP splitting also happens. At that\npoint, both the VMA and the rmap(s) are write-locked.\n\nAn annoying detail is that we can now call into the helper\nhugetlb_unshare_pmds() from two different locking contexts:\n\n1. from hugetlb_split(), holding:\n - mmap lock (exclusively)\n - VMA lock\n - file rmap lock (exclusively)\n2. hugetlb_unshare_all_pmds(), which I think is designed to be able to\n call us with only the mmap lock held (in shared mode), but currently\n only runs while holding mmap lock (exclusively) and VMA lock\n\nBackporting note:\nThis commit fixes a racy protection that was introduced in commit\nb30c14cd6102 (\u0026quot;hugetlb: unshare some PMDs when splitting VMAs\u0026quot;); that\ncommit claimed to fix an issue introduced in 5.13, but it should actually\nalso go all the way back.\n\n[(CVE-2025-38084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/iopl: Cure TIF_IO_BITMAP inconsistencies\n\nio_bitmap_exit() is invoked from exit_thread() when a task exists or\nwhen a fork fails. In the latter case the exit_thread() cleans up\nresources which were allocated during fork().\n\nio_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up\nin tss_update_io_bitmap(). tss_update_io_bitmap() operates on the\ncurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,\ntss_update_io_bitmap() crashes with a NULL pointer dereference.\n\nThere are two issues, which lead to that problem:\n\n 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when\n the task, which is cleaned up, is not the current task. That\u0026apos;s a\n clear indicator for a cleanup after a failed fork().\n\n 2) A task should not have TIF_IO_BITMAP set and neither a bitmap\n installed nor IOPL emulation level 3 activated.\n\n This happens when a kernel thread is created in the context of\n a user space thread, which has TIF_IO_BITMAP set as the thread\n flags are copied and the IO bitmap pointer is cleared.\n\n Other than in the failed fork() case this has no impact because\n kernel threads including IO workers never return to user space and\n therefore never invoke tss_update_io_bitmap().\n\nCure this by adding the missing cleanups and checks:\n\n 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if\n the to be cleaned up task is not the current task.\n\n 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user\n space forks it is set later, when the IO bitmap is inherited in\n io_bitmap_share().\n\nFor paranoia sake, add a warning into tss_update_io_bitmap() to catch\nthe case, when that code is invoked with inconsistent state.(CVE-2025-38100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: marvell/cesa - Handle zero-length skcipher requests\n\nDo not access random memory for zero-length skcipher requests.\nJust return 0.(CVE-2025-38173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var\n\nIf fb_add_videomode() in fb_set_var() fails to allocate memory for\nfb_videomode, later it may lead to a null-ptr dereference in\nfb_videomode_to_var(), as the fb_info is registered while not having the\nmode in modelist that is expected to be there, i.e. the one that is\ndescribed in fb_info-\u0026gt;var.\n\n================================================================\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901\nCall Trace:\n display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929\n fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071\n resize_screen drivers/tty/vt/vt.c:1176 [inline]\n vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263\n fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720\n fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776\n do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128\n fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203\n vfs_ioctl fs/ioctl.c:48 [inline]\n __do_sys_ioctl fs/ioctl.c:753 [inline]\n __se_sys_ioctl fs/ioctl.c:739 [inline]\n __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739\n do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x67/0xd1\n================================================================\n\nThe reason is that fb_info-\u0026gt;var is being modified in fb_set_var(), and\nthen fb_videomode_to_var() is called. If it fails to add the mode to\nfb_info-\u0026gt;modelist, fb_set_var() returns error, but does not restore the\nold value of fb_info-\u0026gt;var. Restore fb_info-\u0026gt;var on failure the same way\nit is done earlier in the function.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-38214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Fix crash when rebind ccp device for ccp.ko\n\nWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding\nthe ccp device causes the following crash:\n\n$ echo \u0026apos;0000:0a:00.2\u0026apos; \u0026gt; /sys/bus/pci/drivers/ccp/unbind\n$ echo \u0026apos;0000:0a:00.2\u0026apos; \u0026gt; /sys/bus/pci/drivers/ccp/bind\n\n[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[ 204.978026] #PF: supervisor write access in kernel mode\n[ 204.979126] #PF: error_code(0x0002) - not-present page\n[ 204.980226] PGD 0 P4D 0\n[ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI\n...\n[ 204.997852] Call Trace:\n[ 204.999074] \u0026lt;TASK\u0026gt;\n[ 205.000297] start_creating+0x9f/0x1c0\n[ 205.001533] debugfs_create_dir+0x1f/0x170\n[ 205.002769] ? srso_return_thunk+0x5/0x5f\n[ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp]\n[ 205.005241] ccp5_init+0x8b2/0x960 [ccp]\n[ 205.006469] ccp_dev_init+0xd4/0x150 [ccp]\n[ 205.007709] sp_init+0x5f/0x80 [ccp]\n[ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp]\n[ 205.010165] ? srso_return_thunk+0x5/0x5f\n[ 205.011376] local_pci_probe+0x4f/0xb0\n[ 205.012584] pci_device_probe+0xdb/0x230\n[ 205.013810] really_probe+0xed/0x380\n[ 205.015024] __driver_probe_device+0x7e/0x160\n[ 205.016240] device_driver_attach+0x2f/0x60\n[ 205.017457] bind_store+0x7c/0xb0\n[ 205.018663] drv_attr_store+0x28/0x40\n[ 205.019868] sysfs_kf_write+0x5f/0x70\n[ 205.021065] kernfs_fop_write_iter+0x145/0x1d0\n[ 205.022267] vfs_write+0x308/0x440\n[ 205.023453] ksys_write+0x6d/0xe0\n[ 205.024616] __x64_sys_write+0x1e/0x30\n[ 205.025778] x64_sys_call+0x16ba/0x2150\n[ 205.026942] do_syscall_64+0x56/0x1e0\n[ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 205.029276] RIP: 0033:0x7fbc36f10104\n[ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5\n\nThis patch sets ccp_debugfs_dir to NULL after destroying it in\nccp5_debugfs_destroy, allowing the directory dentry to be\nrecreated when rebinding the ccp device.\n\nTested on AMD Ryzen 7 1700X.(CVE-2025-38581)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: fix null pointer access\n\nWriting a string without delimiters (\u0026apos; \u0026apos;, \u0026apos;\\n\u0026apos;, \u0026apos;\\0\u0026apos;) to the under\ngpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile\nwill result in a null pointer dereference.(CVE-2025-38705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: kcm: Fix race condition in kcm_unattach()\n\nsyzbot found a race condition when kcm_unattach(psock)\nand kcm_release(kcm) are executed at the same time.\n\nkcm_unattach() is missing a check of the flag\nkcm-\u0026gt;tx_stopped before calling queue_work().\n\nIf the kcm has a reserved psock, kcm_unattach() might get executed\nbetween cancel_work_sync() and unreserve_psock() in kcm_release(),\nrequeuing kcm-\u0026gt;tx_work right before kcm gets freed in kcm_done().\n\nRemove kcm-\u0026gt;tx_stopped and replace it by the less\nerror-prone disable_work_sync().(CVE-2025-38717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()\n\nWe can\u0026apos;t call destroy_workqueue(smb_direct_wq); before stop_sessions()!\n\nOtherwise already existing connections try to use smb_direct_wq as\na NULL pointer.(CVE-2025-39692)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Fix SCCB present check\n\nTracing code called by the SCLP interrupt handler contains early exits\nif the SCCB address associated with an interrupt is NULL. This check is\nperformed after physical to virtual address translation.\n\nIf the kernel identity mapping does not start at address zero, the\nresulting virtual address is never zero, so that the NULL checks won\u0026apos;t\nwork. Subsequently this may result in incorrect accesses to the first\npage of the identity mapping.\n\nFix this by introducing a function that handles the NULL case before\naddress translation.(CVE-2025-39694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet, hsr: reject HSR frame if skb can\u0026apos;t hold tag\n\nReceiving HSR frame with insufficient space to hold HSR tag in the skb\ncan result in a crash (kernel BUG):\n\n[ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1\n[ 45.392559] ------------[ cut here ]------------\n[ 45.392912] kernel BUG at net/core/skbuff.c:211!\n[ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)\n[ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0\n\n\u0026lt;snip registers, remove unreliable trace\u0026gt;\n\n[ 45.402911] Call Trace:\n[ 45.403105] \u0026lt;IRQ\u0026gt;\n[ 45.404470] skb_push+0xcd/0xf0\n[ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0\n[ 45.406513] br_forward_finish+0x128/0x260\n[ 45.408483] __br_forward+0x42d/0x590\n[ 45.409464] maybe_deliver+0x2eb/0x420\n[ 45.409763] br_flood+0x174/0x4a0\n[ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0\n[ 45.411618] br_handle_frame+0xac3/0x1230\n[ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0\n[ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0\n[ 45.424478] __netif_receive_skb+0x22/0x170\n[ 45.424806] process_backlog+0x242/0x6d0\n[ 45.425116] __napi_poll+0xbb/0x630\n[ 45.425394] net_rx_action+0x4d1/0xcc0\n[ 45.427613] handle_softirqs+0x1a4/0x580\n[ 45.427926] do_softirq+0x74/0x90\n[ 45.428196] \u0026lt;/IRQ\u0026gt;\n\nThis issue was found by syzkaller.\n\nThe panic happens in br_dev_queue_push_xmit() once it receives a\ncorrupted skb with ETH header already pushed in linear data. When it\nattempts the skb_push() call, there\u0026apos;s not enough headroom and\nskb_push() panics.\n\nThe corrupted skb is put on the queue by HSR layer, which makes a\nsequence of unintended transformations when it receives a specific\ncorrupted HSR frame (with incomplete TAG).\n\nFix it by dropping and consuming frames that are not long enough to\ncontain both ethernet and hsr headers.\n\nAlternative fix would be to check for enough headroom before skb_push()\nin br_dev_queue_push_xmit().\n\nIn the reproducer, this is injected via AF_PACKET, but I don\u0026apos;t easily\nsee why it couldn\u0026apos;t be sent over the wire from adjacent network.\n\nFurther Details:\n\nIn the reproducer, the following network interface chain is set up:\n\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 veth0_to_hsr \u251c\u2500\u2500\u2500\u2524 hsr_slave0 \u253c\u2500\u2500\u2500\u2510\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\n \u2502 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u251c\u2500\u2524 hsr0 \u251c\u2500\u2500\u2500\u2510\n \u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502 \u2502\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 veth1_to_hsr \u253c\u2500\u2500\u2500\u2524 hsr_slave1 \u251c\u2500\u2500\u2500\u2518 \u2514\u2524 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u250c\u253c bridge \u2502\n \u2502\u2502 \u2502\n \u2502\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502\n \u2502 ... \u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\nTo trigger the events leading up to crash, reproducer sends a corrupted\nHSR fr\n---truncated---(CVE-2025-39703)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39751)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Set merge to zero early in af_alg_sendmsg\n\nIf an error causes af_alg_sendmsg to abort, ctx-\u0026gt;merge may contain\na garbage value from the previous loop. This may then trigger a\ncrash on the next entry into af_alg_sendmsg when it attempts to do\na merge that can\u0026apos;t be done.\n\nFix this by setting ctx-\u0026gt;merge to zero near the start of the loop.(CVE-2025-39931)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed\n\nIf earlier opening of source graph fails (e.g. ADSP rejects due to\nincorrect audioreach topology), the graph is closed and\n\u0026quot;dai_data-\u0026gt;graph[dai-\u0026gt;id]\u0026quot; is assigned NULL. Preparing the DAI for sink\ngraph continues though and next call to q6apm_lpass_dai_prepare()\nreceives dai_data-\u0026gt;graph[dai-\u0026gt;id]=NULL leading to NULL pointer\nexception:\n\n qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd\n qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1\n q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78\n q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22\n Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8\n ...\n Call trace:\n q6apm_graph_media_format_pcm+0x48/0x120 (P)\n q6apm_lpass_dai_prepare+0x110/0x1b4\n snd_soc_pcm_dai_prepare+0x74/0x108\n __soc_pcm_prepare+0x44/0x160\n dpcm_be_dai_prepare+0x124/0x1c0(CVE-2025-39938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-stripe: fix a possible integer overflow\n\nThere\u0026apos;s a possible integer overflow in stripe_io_hints if we have too\nlarge chunk size. Test if the overflow happened, and if it did, don\u0026apos;t set\nlimits-\u0026gt;io_min and limits-\u0026gt;io_opt;(CVE-2025-39940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - Disallow concurrent writes in af_alg_sendmsg\n\nIssuing two writes to the same af_alg socket is bogus as the\ndata will be interleaved in an unpredictable fashion. Furthermore,\nconcurrent writes may create inconsistencies in the internal\nsocket state.\n\nDisallow this by adding a new ctx-\u0026gt;write field that indiciates\nexclusive ownership for writing.(CVE-2025-39964)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: swap: check for stable address space before operating on the VMA\n\nIt is possible to hit a zero entry while traversing the vmas in unuse_mm()\ncalled from swapoff path and accessing it causes the OOPS:\n\nUnable to handle kernel NULL pointer dereference at virtual address\n0000000000000446--\u0026gt; Loading the memory from offset 0x40 on the\nXA_ZERO_ENTRY as address.\nMem abort info:\n ESR = 0x0000000096000005\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x05: level 1 translation fault\n\nThe issue is manifested from the below race between the fork() on a\nprocess and swapoff:\nfork(dup_mmap())\t\t\tswapoff(unuse_mm)\n--------------- -----------------\n1) Identical mtree is built using\n __mt_dup().\n\n2) copy_pte_range()--\u0026gt;\n\tcopy_nonpresent_pte():\n The dst mm is added into the\n mmlist to be visible to the\n swapoff operation.\n\n3) Fatal signal is sent to the parent\nprocess(which is the current during the\nfork) thus skip the duplication of the\nvmas and mark the vma range with\nXA_ZERO_ENTRY as a marker for this process\nthat helps during exit_mmap().\n\n\t\t\t\t 4) swapoff is tried on the\n\t\t\t\t\t\u0026apos;mm\u0026apos; added to the \u0026apos;mmlist\u0026apos; as\n\t\t\t\t\tpart of the 2.\n\n\t\t\t\t 5) unuse_mm(), that iterates\n\t\t\t\t\tthrough the vma\u0026apos;s of this \u0026apos;mm\u0026apos;\n\t\t\t\t\twill hit the non-NULL zero entry\n\t\t\t\t\tand operating on this zero entry\n\t\t\t\t\tas a vma is resulting into the\n\t\t\t\t\toops.\n\nThe proper fix would be around not exposing this partially-valid tree to\nothers when droping the mmap lock, which is being solved with [1]. A\nsimpler solution would be checking for MMF_UNSTABLE, as it is set if\nmm_struct is not fully initialized in dup_mmap().\n\nThanks to Liam/Lorenzo/David for all the suggestions in fixing this\nissue.(CVE-2025-39992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix warning in smc_rx_splice() when calling get_page()\n\nsmc_lo_register_dmb() allocates DMB buffers with kzalloc(), which are\nlater passed to get_page() in smc_rx_splice(). Since kmalloc memory is\nnot page-backed, this triggers WARN_ON_ONCE() in get_page() and prevents\nholding a refcount on the buffer. This can lead to use-after-free if\nthe memory is released before splice_to_pipe() completes.\n\nUse folio_alloc() instead, ensuring DMBs are page-backed and safe for\nget_page().\n\nWARNING: CPU: 18 PID: 12152 at ./include/linux/mm.h:1330 smc_rx_splice+0xaf8/0xe20 [smc]\nCPU: 18 UID: 0 PID: 12152 Comm: smcapp Kdump: loaded Not tainted 6.17.0-rc3-11705-g9cf4672ecfee #10 NONE\nHardware name: IBM 3931 A01 704 (z/VM 7.4.0)\nKrnl PSW : 0704e00180000000 000793161032696c (smc_rx_splice+0xafc/0xe20 [smc])\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\nKrnl GPRS: 0000000000000000 001cee80007d3001 00077400000000f8 0000000000000005\n 0000000000000001 001cee80007d3006 0007740000001000 001c000000000000\n 000000009b0c99e0 0000000000001000 001c0000000000f8 001c000000000000\n 000003ffcc6f7c88 0007740003e98000 0007931600000005 000792969b2ff7b8\nKrnl Code: 0007931610326960: af000000\t\tmc\t0,0\n 0007931610326964: a7f4ff43\t\tbrc\t15,00079316103267ea\n #0007931610326968: af000000\t\tmc\t0,0\n \u0026gt;000793161032696c: a7f4ff3f\t\tbrc\t15,00079316103267ea\n 0007931610326970: e320f1000004\tlg\t%r2,256(%r15)\n 0007931610326976: c0e53fd1b5f5\tbrasl\t%r14,000793168fd5d560\n 000793161032697c: a7f4fbb5\t\tbrc\t15,00079316103260e6\n 0007931610326980: b904002b\t\tlgr\t%r2,%r11\nCall Trace:\n smc_rx_splice+0xafc/0xe20 [smc]\n smc_rx_splice+0x756/0xe20 [smc])\n smc_rx_recvmsg+0xa74/0xe00 [smc]\n smc_splice_read+0x1ce/0x3b0 [smc]\n sock_splice_read+0xa2/0xf0\n do_splice_read+0x198/0x240\n splice_file_to_pipe+0x7e/0x110\n do_splice+0x59e/0xde0\n __do_splice+0x11a/0x2d0\n __s390x_sys_splice+0x140/0x1f0\n __do_syscall+0x122/0x280\n system_call+0x6e/0x90\nLast Breaking-Event-Address:\nsmc_rx_splice+0x960/0xe20 [smc]\n---[ end trace 0000000000000000 ]---(CVE-2025-40012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak\n\nStruct ff_effect_compat is embedded twice inside\nuinput_ff_upload_compat, contains internal padding. In particular, there\nis a hole after struct ff_replay to satisfy alignment requirements for\nthe following union member. Without clearing the structure,\ncopy_to_user() may leak stack data to userspace.\n\nInitialize ff_up_compat to zero before filling valid fields.(CVE-2025-40035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: nci: Add parameter validation for packet data\n\nSyzbot reported an uninitialized value bug in nci_init_req, which was\nintroduced by commit 5aca7966d2a7 (\u0026quot;Merge tag\n\u0026apos;perf-tools-fixes-for-v6.17-2025-09-16\u0026apos; of\ngit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools\u0026quot;).\n\nThis bug arises due to very limited and poor input validation\nthat was done at nic_valid_size(). This validation only\nvalidates the skb-\u0026gt;len (directly reflects size provided at the\nuserspace interface) with the length provided in the buffer\nitself (interpreted as NCI_HEADER). This leads to the processing\nof memory content at the address assuming the correct layout\nper what opcode requires there. This leads to the accesses to\nbuffer of `skb_buff-\u0026gt;data` which is not assigned anything yet.\n\nFollowing the same silent drop of packets of invalid sizes at\n`nic_valid_size()`, add validation of the data in the respective\nhandlers and return error values in case of failure. Release\nthe skb if error values are returned from handlers in\n`nci_nft_packet` and effectively do a silent drop\n\nPossible TODO: because we silently drop the packets, the\ncall to `nci_request` will be waiting for completion of request\nand will face timeouts. These timeouts can get excessively logged\nin the dmesg. A proper handling of them may require to export\n`nci_request_cancel` (or propagate error handling from the\nnft packets handlers).(CVE-2025-40043)\n\nIn the Linux kernel, a race condition vulnerability exists in the uio_hv_generic driver. The driver\u0026apos;s default interrupt mask setting logic is flawed, as the interrupt mask value should be completely controlled by user space. If the mask bit gets changed by the driver concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, causing the user-mode driver to miss an interrupt and leading to a system hang.\n\nSpecifically, when the driver sets the inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. This results in the host putting a message into the ring buffer without interruption. Subsequently, when user space code in the guest sets the inbound ring buffer interrupt mask to 0 and waits for an interrupt via pread(), since there\u0026apos;s already a message in the ring buffer, no new interrupt is generated, causing pread() to wait indefinitely.\n\nThe fix removes all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable user space control of the interrupt mask by writing 0/1 to /dev/uioX.(CVE-2025-40048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dlink: handle copy_thresh allocation failure\n\nThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.\nIf the allocation failed, dereferencing `skb-\u0026gt;protocol` could lead to\na NULL pointer dereference.\n\nThis patch tries to allocate `skb`. If the allocation fails, it falls\nback to the normal path.\n\nTested-on: D-Link DGE-550T Rev-A3(CVE-2025-40053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix double free in user_cluster_connect()\n\nuser_cluster_disconnect() frees \u0026quot;conn-\u0026gt;cc_private\u0026quot; which is \u0026quot;lc\u0026quot; but then\nthe error handling frees \u0026quot;lc\u0026quot; a second time. Set \u0026quot;lc\u0026quot; to NULL on this\npath to avoid a double free.(CVE-2025-40055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nBUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186\nRead of size 2 at addr ffff8880289ef218 by task syz.6.248/14290\n\nCPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x5f0 mm/kasan/report.c:482\n kasan_report+0xca/0x100 mm/kasan/report.c:595\n hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186\n hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738\n vfs_listxattr+0xbe/0x140 fs/xattr.c:493\n listxattr+0xee/0x190 fs/xattr.c:924\n filename_listxattr fs/xattr.c:958 [inline]\n path_listxattrat+0x143/0x360 fs/xattr.c:988\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe0e9fae16d\nCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3\nRAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000\nRBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 14290:\n kasan_save_stack+0x24/0x50 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4333 [inline]\n __kmalloc_noprof+0x219/0x540 mm/slub.c:4345\n kmalloc_noprof include/linux/slab.h:909 [inline]\n hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21\n hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697\n vfs_listxattr+0xbe/0x140 fs/xattr.c:493\n listxattr+0xee/0x190 fs/xattr.c:924\n filename_listxattr fs/xattr.c:958 [inline]\n path_listxattrat+0x143/0x360 fs/xattr.c:988\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWhen hfsplus_uni2asc is called from hfsplus_listxattr,\nit actually passes in a struct hfsplus_attr_unistr*.\nThe size of the corresponding structure is different from that of hfsplus_unistr,\nso the previous fix (94458781aee6) is insufficient.\nThe pointer on the unicode buffer is still going beyond the allocated memory.\n\nThis patch introduces two warpper functions hfsplus_uni2asc_xattr_str and\nhfsplus_uni2asc_str to process two unicode buffers,\nstruct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.\nWhen ustrlen value is bigger than the allocated memory size,\nthe ustrlen value is limited to an safe size.(CVE-2025-40082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: transport_ipc: validate payload size before reading handle\n\nhandle_response() dereferences the payload as a 4-byte handle without\nverifying that the declared payload size is at least 4 bytes. A malformed\nor truncated message from ksmbd.mountd can lead to a 4-byte read past the\ndeclared payload size. Validate the size before dereferencing.\n\nThis is a minimal fix to guard the initial handle read.(CVE-2025-40084)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the hfsplus_strcasecmp() function of the hfsplus filesystem. When the hfsplus_strcasecmp() logic is triggered, it causes a slab-out-of-bounds read, allowing attackers to read sensitive information from kernel memory. This vulnerability triggers KASAN-detected boundary check errors and could be exploited for information disclosure or system crash attacks.(CVE-2025-40088)\n\nIn the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present. Ensure that set_ent is always set since only drbg provides it. The Linux kernel CVE team has assigned CVE-2025-40109 to this issue.(CVE-2025-40109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix a null-ptr access in the cursor snooper\n\nCheck that the resource which is converted to a surface exists before\ntrying to use the cursor snooper on it.\n\nvmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers\nbecause some svga commands accept SVGA3D_INVALID_ID to mean \u0026quot;no surface\u0026quot;,\nunfortunately functions that accept the actual surfaces as objects might\n(and in case of the cursor snooper, do not) be able to handle null\nobjects. Make sure that we validate not only the identifier (via the\nvmw_cmd_res_check) but also check that the actual resource exists before\ntrying to do something with it.\n\nFixes unchecked null-ptr reference in the snooping code.(CVE-2025-40110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock\n\nPrevent USB runtime PM (autosuspend) for AX88772* in bind.\n\nusbnet enables runtime PM (autosuspend) by default, so disabling it via\nthe usb_driver flag is ineffective. On AX88772B, autosuspend shows no\nmeasurable power saving with current driver (no link partner, admin\nup/down). The ~0.453 W -\u0026gt; ~0.248 W drop on v6.1 comes from phylib powering\nthe PHY off on admin-down, not from USB autosuspend.\n\nThe real hazard is that with runtime PM enabled, ndo_open() (under RTNL)\nmay synchronously trigger autoresume (usb_autopm_get_interface()) into\nasix_resume() while the USB PM lock is held. Resume paths then invoke\nphylink/phylib and MDIO, which also expect RTNL, leading to possible\ndeadlocks or PM lock vs MDIO wake issues.\n\nTo avoid this, keep the device runtime-PM active by taking a usage\nreference in ax88772_bind() and dropping it in unbind(). A non-zero PM\nusage count blocks runtime suspend regardless of userspace policy\n(.../power/control - pm_runtime_allow/forbid), making this approach\nrobust against sysfs overrides.\n\nHolding a runtime-PM usage ref does not affect system-wide suspend;\nsystem sleep/resume callbacks continue to run as before.(CVE-2025-40120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Enforce expected_attach_type for tailcall compatibility\n\nYinhao et al. recently reported:\n\n Our fuzzer tool discovered an uninitialized pointer issue in the\n bpf_prog_test_run_xdp() function within the Linux kernel\u0026apos;s BPF subsystem.\n This leads to a NULL pointer dereference when a BPF program attempts to\n deference the txq member of struct xdp_buff object.\n\nThe test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the\nentry point for bpf_prog_test_run_xdp() and its expected_attach_type can\nneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot\nof a tailcall map it owns. progB\u0026apos;s expected_attach_type must be BPF_XDP_DEVMAP\nto pass xdp_is_valid_access() validation. The program returns struct xdp_md\u0026apos;s\negress_ifindex, and the latter is only allowed to be accessed under mentioned\nexpected_attach_type. progB is then inserted into the tailcall which progA\ncalls.\n\nThe underlying issue goes beyond XDP though. Another example are programs\nof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well\nas sock_addr_func_proto() have different logic depending on the programs\u0026apos;\nexpected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME\nshould not be allowed doing a tailcall into a program which calls bpf_bind()\nout of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.\n\nIn short, specifying expected_attach_type allows to open up additional\nfunctionality or restrictions beyond what the basic bpf_prog_type enables.\nThe use of tailcalls must not violate these constraints. Fix it by enforcing\nexpected_attach_type in __bpf_prog_map_compatible().\n\nNote that we only enforce this for tailcall maps, but not for BPF devmaps or\ncpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and\ncpu_map_bpf_prog_run*() which set up a new environment / context and therefore\nthese situations are not prone to this issue.(CVE-2025-40123)\n\nIn the Linux kernel, a vulnerability exists in the blk-mq component: the return value of blk_mq_sysfs_register_hctxs() is not checked in __blk_mq_update_nr_hw_queues() function. If sysfs creation for hctx fails, later changing the number of hw_queues or removing disk will trigger kernel warnings. The issue occurs because kobject_del() is called unconditionally even when sysfs creation fails, leading to kernfs directory operation errors.(CVE-2025-40125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: fix null pointer dereference on zero-length checksum\n\nIn xdr_stream_decode_opaque_auth(), zero-length checksum.len causes\nchecksum.data to be set to NULL. This triggers a NPD when accessing\nchecksum.data in gss_krb5_verify_mic_v2(). This patch ensures that\nthe value of checksum.len is not less than XDR_UNIT.(CVE-2025-40129)\n\nIn the Linux kernel, there is a race condition between device manager (dm) suspend and table load that can lead to null pointer dereference. The issue occurs when suspend is invoked before table load completes, causing q-\u0026gt;tag_set to be a NULL pointer and leading to system crash. The vulnerability affects Linux kernel versions from 5.0 to 6.17.2.(CVE-2025-40134)\n\nIn the Linux kernel, a race condition vulnerability exists in the rtl8150 USB network driver\u0026apos;s rtl8150_set_multicast function. The vulnerability occurs because rtl8150_set_multicast incorrectly calls netif_stop_queue and netif_wake_queue, causing TX queue synchronization issues. When rtl8150_set_multicast wakes up the TX queue before USB transfer completion, it may lead to double submission of URB in rtl8150_start_xmit, resulting in warnings and potential system instability.(CVE-2025-40140)\n\nIn the Linux kernel, a use-after-free vulnerability has been identified in the Bluetooth ISO module. This vulnerability is similar to the issue in sco_conn_free where if conn-\u0026gt;sk is not set to NULL, it may lead to use-after-free in iso_conn_free.(CVE-2025-40141)\n\nA vulnerability was found in the Linux kernel where calling mprotect() on large hugetlb memory areas (approximately 300GB) can cause soft lockup issues. The CPU becomes stuck for extended periods, making the system unresponsive. This occurs because the hugetlb handling for large memory lacks proper scheduling opportunities, unlike THP or base pages which already have cond_resched() calls. Although the soft lockup was triggered by MTE, this is not MTE-specific - any processing that takes a long time in the loop may trigger soft lockup.(CVE-2025-40153)\n\nIn the Linux kernel, the usbnet driver contains a stack-based buffer overflow vulnerability. Syzbot reported warnings about using smp_processor_id() in preemptible code. This vulnerability may lead to stack buffer overflow, affecting system confidentiality, integrity, and availability. The vulnerability stems from the incorrect use of smp_processor_id() function in the usbnet_skb_return function within preemptible context.(CVE-2025-40164)\n\nIn the Linux kernel, a vulnerability has been found in the ext4 filesystem. When opening a verity file on a corrupted ext4 filesystem mounted without a journal, syzbot reported a BUG_ON in ext4_es_cache_extent(). The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set. This is an invalid combination since an inode should have either: INLINE_DATA (data stored directly in the inode) or EXTENTS (data stored in extent-mapped blocks). Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes.(CVE-2025-40167)\n\nIn the Linux kernel, the check_alu_op() function in the BPF verifier contains a vulnerability when validating ALU operation instructions. The function validates BPF program instructions where the \u0026apos;offset\u0026apos; field is a signed 16-bit integer. The original check condition \u0026apos;insn-\u0026gt;off \u0026gt; 1\u0026apos; was intended to ensure the offset is either 0 or 1 (for BPF_MOD/BPF_DIV operations). However, since \u0026apos;insn-\u0026gt;off\u0026apos; is signed, this check incorrectly accepts all negative values (e.g., -1). This vulnerability allows maliciously crafted BPF programs to bypass verification, potentially leading to privilege escalation and other security issues.(CVE-2025-40169)\n\nIn the Linux kernel, a vulnerability has been found in the nvmet-fc module. When multiple async commands are in flight from __nvmet_fc_send_ls_req, a tgtport reference is taken for each command. In the current code, only one put work item is queued at a time, which results in a leaked reference. This vulnerability affects multiple Linux kernel version branches.(CVE-2025-40171)\n\nIn the Linux kernel, a vulnerability has been identified in the net/ip6_tunnel module. Similar to IPv4 tunnel, IPv6 version also updates dev-\u0026gt;needed_headroom. While IPv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd, the IPv6 tunnel continues to increase headroom without any ceiling. This vulnerability may lead to perpetual tunnel growth, affecting system confidentiality, integrity, and availability, with potential privilege escalation risks.(CVE-2025-40173)\n\nIn the Linux kernel, during asynchronous decryption in the TLS module, the tls_strp_msg_hold function is called to create a clone of the input skb to hold references to the memory it uses. If the allocation of this clone fails, proceeding with asynchronous decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, the system should wait for all pending decryption requests to complete.(CVE-2025-40176)\n\nIn the Linux kernel, there is a NULL pointer dereference vulnerability in the pid_nr_ns function. When task_active_pid_ns returns null, it triggers kernel panic. The vulnerability manifests as kernel panic when task_active_pid_ns returns null in the pid_nr_ns function. The vulnerability example shows inability to handle kernel NULL pointer dereference errors, leading to system crash. The specific error is \u0026apos;Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058\u0026apos;, ultimately causing kernel panic and system crash.(CVE-2025-40178)\n\nIn the Linux kernel, the ext4 filesystem has a vulnerability: orphan files can be arbitrarily large in principle. However, orphan replay needs to traverse all content and pin all buffers in memory. Filesystems with absurdly large orphan files can lead to significant memory consumption. The vulnerability limits orphan file size to a sane value and uses kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for large orphan files.(CVE-2025-40179)\n\nIn the Linux kernel, a memory leak vulnerability exists. Cilium\u0026apos;s BPF egress gateway feature redirects K8s Pod traffic through vxlan tunnels to dedicated egress gateways. When using the bpf_redirect_neigh() helper to forward packets, vxlan allocates metadata_dst objects and attaches them to skb through fake dst entries. However, since bpf_redirect_neigh() only sets new dst entries without first dropping existing ones, the metadata_dst objects are never released, causing continuous increase in kmalloc-256 slab usage.(CVE-2025-40183)\n\nIn the Linux kernel, a NULL pointer dereference vulnerability exists in the SCTP protocol. When new_asoc-\u0026gt;peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0, and sctp_ulpevent_make_authkey() returns 0, the variable ai_ev remains zero and this zero value will be dereferenced in the sctp_ulpevent_free() function.(CVE-2025-40187)\n\nIn the Linux kernel, there is a reference count underflow vulnerability in the ext4 file system. Syzkaller discovered a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already \u0026lt;= 0 and then applies ref_change (often -1), causing the refcount to underflow and proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode ref underflow, EXT4-fs warning: ea_inode dec ref err. The fix makes the invariant explicit: if the current refcount is non-positive, treat it as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount.(CVE-2025-40190)\n\nIn the Linux kernel, the following vulnerability has been resolved: Revert \u0026quot;ipmi: fix msg stack when IPMI is disconnected\u0026quot;. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.(CVE-2025-40192)\n\nIn the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request(). The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.(CVE-2025-40194)\n\nIn the Linux kernel, a buffer over-read vulnerability has been discovered in the parse_apply_sb_mount_options() function of the ext4 filesystem. Unlike other strings in the ext4 superblock, this vulnerability relies on tune2fs to ensure s_mount_opts is NUL terminated. The parse_apply_sb_mount_options() function has been hardened by treating s_mount_opts as a potential __nonstring.(CVE-2025-40198)\n\nIn the Linux kernel, a vulnerability has been identified in the Squashfs filesystem\u0026apos;s squashfs_read_inode() function, which fails to properly validate input data and may accept negative file sizes. Syskaller reports a \u0026quot;WARNING in ovl_copy_up_file\u0026quot; in overlayfs. This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size. This commit fixes the issue by checking for negative file sizes and returning EINVAL.(CVE-2025-40200)\n\nIn the Linux kernel, the sys_prlimit64() path has a race condition issue with the usage of task_lock(tsk-\u0026gt;group_leader). When tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk-\u0026gt;group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes -\u0026gt;group_leader. In this case do_prlimit() may take the wrong lock, or (worse) -\u0026gt;group_leader may change between task_lock() and task_unlock(). The fix changes sys_prlimit64() to take tasklist_lock when necessary.(CVE-2025-40201)\n\nIn the Linux kernel, the IPMI subsystem\u0026apos;s user message limit handling had a number of issues, including improper counting in some cases and a use-after-free vulnerability. The vulnerability has been resolved by restructuring the handling to manage more in the receive message allocation routine, where all referencing and user message limit counts are now handled, making the process cleaner and safer. This vulnerability affects Linux Kernel versions from 5.19 to 6.18-rc1.(CVE-2025-40202)\n\nIn the Linux kernel, the SCTP protocol\u0026apos;s MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)\n\nIn the Linux kernel, the netfilter nft_objref module has a validation bypass vulnerability. Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls. This vulnerability allows attackers to trigger kernel stack overflow through specially crafted nftables rules, leading to system crash. Validation functions for objref and objrefmap expressions have been implemented, currently only NFT_OBJECT_SYNPROXY object type requires validation.(CVE-2025-40206)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the ACPI video subsystem. The switch_brightness_work delayed work accesses device-\u0026gt;brightness and device-\u0026gt;backlight, which are freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device-\u0026gt;brightness or device-\u0026gt;backlight. The issue is fixed by calling cancel_delayed_work_sync() for each device\u0026apos;s switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work, ensuring the work completes before the memory is freed.(CVE-2025-40211)",
"id": "OESA-2025-2766",
"modified": "2026-08-06T11:09:53Z",
"published": "2025-11-28T11:09:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2766"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36357"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38100"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38581"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38717"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39692"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39694"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39703"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39751"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39940"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39964"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40012"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40035"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40088"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40109"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40110"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40123"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40134"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40140"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40164"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40167"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40169"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40171"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40173"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40176"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40178"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40183"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40187"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40200"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40204"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40211"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-36357",
"CVE-2025-21915",
"CVE-2025-22080",
"CVE-2025-23150",
"CVE-2025-37785",
"CVE-2025-37828",
"CVE-2025-38084",
"CVE-2025-38100",
"CVE-2025-38173",
"CVE-2025-38214",
"CVE-2025-38581",
"CVE-2025-38705",
"CVE-2025-38717",
"CVE-2025-38729",
"CVE-2025-39692",
"CVE-2025-39694",
"CVE-2025-39703",
"CVE-2025-39751",
"CVE-2025-39931",
"CVE-2025-39938",
"CVE-2025-39940",
"CVE-2025-39964",
"CVE-2025-39992",
"CVE-2025-40012",
"CVE-2025-40035",
"CVE-2025-40043",
"CVE-2025-40048",
"CVE-2025-40053",
"CVE-2025-40055",
"CVE-2025-40082",
"CVE-2025-40084",
"CVE-2025-40088",
"CVE-2025-40109",
"CVE-2025-40110",
"CVE-2025-40120",
"CVE-2025-40123",
"CVE-2025-40125",
"CVE-2025-40129",
"CVE-2025-40134",
"CVE-2025-40140",
"CVE-2025-40141",
"CVE-2025-40153",
"CVE-2025-40164",
"CVE-2025-40167",
"CVE-2025-40169",
"CVE-2025-40171",
"CVE-2025-40173",
"CVE-2025-40176",
"CVE-2025-40178",
"CVE-2025-40179",
"CVE-2025-40183",
"CVE-2025-40187",
"CVE-2025-40190",
"CVE-2025-40192",
"CVE-2025-40194",
"CVE-2025-40198",
"CVE-2025-40200",
"CVE-2025-40201",
"CVE-2025-40202",
"CVE-2025-40204",
"CVE-2025-40206",
"CVE-2025-40211"
]
}
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.
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…
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.
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.