Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-21727 (GCVE-0-2025-21727)
Vulnerability from cvelistv5 – Published: 2025-02-27 02:07 – Updated: 2026-08-05 11:54- CWE-416 - Use After Free
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
b128a30409356df65f1a51cff3eb986cac8cfedc , < f78170bee51469734b1a306a74fc5f777bb22ba6
(git)
Affected: b128a30409356df65f1a51cff3eb986cac8cfedc , < f3e0b9f790f8e8065d59e67b565a83154d9f3079 (git) Affected: b128a30409356df65f1a51cff3eb986cac8cfedc , < 0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd (git) Affected: b128a30409356df65f1a51cff3eb986cac8cfedc , < bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de (git) Affected: b128a30409356df65f1a51cff3eb986cac8cfedc , < 573ac9c70bf7885dc85d82fa44550581bfc3b738 (git) Affected: b128a30409356df65f1a51cff3eb986cac8cfedc , < 80231f069240d52e98b6a317456c67b2eafd0781 (git) Affected: b128a30409356df65f1a51cff3eb986cac8cfedc , < e01780ea4661172734118d2a5f41bc9720765668 (git) |
guessed | |
| Linux | Linux |
Affected:
5.4
Unaffected: 0 , < 5.4 (semver) Unaffected: 5.10.235 , ≤ 5.10.* (semver) Unaffected: 5.15.179 , ≤ 5.15.* (semver) Unaffected: 6.1.129 , ≤ 6.1.* (semver) Unaffected: 6.6.76 , ≤ 6.6.* (semver) Unaffected: 6.12.13 , ≤ 6.12.* (semver) Unaffected: 6.13.2 , ≤ 6.13.* (semver) Unaffected: 6.14 , ≤ * (original_commit_for_fix) |
guessed | |
| Siemens | SIMATIC S7-1500 TM MFP - GNU/Linux subsystem |
Affected:
0 , < *
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2025-21727",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:58:06.104597Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "CWE-416 Use After Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-02-27T18:02:27.953Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:36:30.604Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T12:03:30.794Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"x_adpType": "supplier"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f78170bee51469734b1a306a74fc5f777bb22ba6",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "f3e0b9f790f8e8065d59e67b565a83154d9f3079",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "573ac9c70bf7885dc85d82fa44550581bfc3b738",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "80231f069240d52e98b6a317456c67b2eafd0781",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "e01780ea4661172734118d2a5f41bc9720765668",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.4"
},
{
"lessThan": "5.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.129",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.76",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.76",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.13",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.2",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "5.4",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0027mdelay(10)\u0027 is added before calling \u0027padata_find_next\u0027 in the\n\u0027padata_reorder\u0027 function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026pd-\u003erefcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u003epd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0027while\u0027, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0027padata_find_next\u0027, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0027padata_free_shell\u0027 wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable padata/pcrypt path is driven through local syscalls \u2014 an AF_ALG socket bound to `pcrypt(...)` submitting aead requests, and the racing teardown via crypto module autoload or the NETLINK_CRYPTO socket. No remote peer can reach or free the padata shell on its own.\nAC:L - The attacker controls both sides of the race: they flood concurrent pcrypt requests to keep `padata_reorder()` spinning in its loop while triggering instance teardown, and can widen the window with CPU contention and many parallel workers. The commit confirms it reproduces with a stock LTP test (pcrypt_aead01) once the loop is delayed, meaning it is a naturally occurring, repeatable window.\nPR:L - A basic unprivileged local user can both instantiate and continuously drive pcrypt via AF_ALG (`alg_bind` performs no capability check) and trigger the teardown side, since `crypto_alg_finish_registration()` \u2192 `crypto_remove_spawns()` destroys the pcrypt instance when an equal-or-higher-priority same-named implementation registers \u2014 a module autoload reachable from the same unprivileged bind path.\nUI:N - Exploitation is entirely attacker-driven through socket operations and crypto requests; no victim action, mount, or file open is required.\nS:U - The use-after-free corrupts kernel slab memory and stays within the kernel\u0027s own security authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - Reclaiming the freed `struct parallel_data` gives the attacker control of `pd-\u003ereorder_list`, whose per-CPU dereference in `padata_find_next()` becomes an attacker-directed kernel read, and `pd-\u003eps-\u003epinst` is likewise dereferenced \u2014 yielding disclosure of arbitrary kernel memory.\nI:H - The same UAF provides write primitives \u2014 `list_del_init()` unlink on an attacker-controlled reorder list, `++pd-\u003eprocessed` / `pd-\u003ecpu` writes, and most severely `queue_work(pinst-\u003eserial_wq, \u0026pd-\u003ereorder_work)` invoking a function pointer living in freed, sprayable memory, enabling control-flow hijack and privilege escalation.\nA:H - Even unweaponized, the slab-use-after-free reported by KASAN dereferences freed percpu and workqueue pointers from a kworker context, reliably producing an oops or kernel panic and taking the system down."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:54:00.224Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6"
},
{
"url": "https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079"
},
{
"url": "https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd"
},
{
"url": "https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de"
},
{
"url": "https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738"
},
{
"url": "https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781"
},
{
"url": "https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668"
}
],
"title": "padata: fix UAF in padata_reorder",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-21727",
"datePublished": "2025-02-27T02:07:33.501Z",
"dateReserved": "2024-12-29T08:45:45.754Z",
"dateUpdated": "2026-08-05T11:54:00.224Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-21727",
"date": "2026-09-17",
"epss": "0.0022",
"percentile": "0.12674"
},
"microsoft_vex": {
"current_release_date": "2026-02-18T01:08:16.000Z",
"cve": "CVE-2025-21727",
"id": "msrc_CVE-2025-21727",
"initial_release_date": "2025-02-02T00:00:00.000Z",
"product_status:known_not_affected": "2",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "padata: fix UAF in padata_reorder",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-21727.json",
"version": "2"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2025-21727\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-02-27T02:15:16.423\",\"lastModified\":\"2026-06-17T08:44:08.047\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\npadata: fix UAF in padata_reorder\\n\\nA bug was found when run ltp test:\\n\\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\\n\\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\\nWorkqueue: pdecrypt_parallel padata_parallel_worker\\nCall Trace:\\n\u003cTASK\u003e\\ndump_stack_lvl+0x32/0x50\\nprint_address_description.constprop.0+0x6b/0x3d0\\nprint_report+0xdd/0x2c0\\nkasan_report+0xa5/0xd0\\npadata_find_next+0x29/0x1a0\\npadata_reorder+0x131/0x220\\npadata_parallel_worker+0x3d/0xc0\\nprocess_one_work+0x2ec/0x5a0\\n\\nIf \u0027mdelay(10)\u0027 is added before calling \u0027padata_find_next\u0027 in the\\n\u0027padata_reorder\u0027 function, this issue could be reproduced easily with\\nltp test (pcrypt_aead01).\\n\\nThis can be explained as bellow:\\n\\npcrypt_aead_encrypt\\n...\\npadata_do_parallel\\nrefcount_inc(\u0026pd-\u003erefcnt); // add refcnt\\n...\\npadata_do_serial\\npadata_reorder // pd\\nwhile (1) {\\npadata_find_next(pd, true); // using pd\\nqueue_work_on\\n...\\npadata_serial_worker\\t\\t\\t\\tcrypto_del_alg\\npadata_put_pd_cnt // sub refcnt\\n\\t\\t\\t\\t\\t\\tpadata_free_shell\\n\\t\\t\\t\\t\\t\\tpadata_put_pd(ps-\u003epd);\\n\\t\\t\\t\\t\\t\\t// pd is freed\\n// loop again, but pd is freed\\n// call padata_find_next, UAF\\n}\\n\\nIn the padata_reorder function, when it loops in \u0027while\u0027, if the alg is\\ndeleted, the refcnt may be decreased to 0 before entering\\n\u0027padata_find_next\u0027, which leads to UAF.\\n\\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\\nand always happen under RCU protection, to address this issue, add\\nsynchronize_rcu() in \u0027padata_free_shell\u0027 wait for all _do_serial calls\\nto finish.\\n\\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: correcci\u00f3n de UAF en padata_reorder Se encontr\u00f3 un error al ejecutar la prueba ltp: ERROR: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If \u0027mdelay(10)\u0027 is added before calling \u0027padata_find_next\u0027 in the \u0027padata_reorder\u0027 function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps-\u0026gt;pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } En la funci\u00f3n padata_reorder, cuando se repite en \u0027while\u0027, si se elimina el alg, el refcnt puede disminuirse a 0 antes de ingresar a \u0027padata_find_next\u0027, lo que lleva a UAF. Como se mencion\u00f3 en [1], se supone que do_serial se debe llamar con los BH deshabilitados y siempre ocurre bajo la protecci\u00f3n de RCU, para abordar este problema, agreguesynchronous_rcu() en \u0027padata_free_shell\u0027 y espere a que finalicen todas las llamadas a _do_serial. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"kernel/padata.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"b128a30409356df65f1a51cff3eb986cac8cfedc\",\"lessThan\":\"f78170bee51469734b1a306a74fc5f777bb22ba6\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b128a30409356df65f1a51cff3eb986cac8cfedc\",\"lessThan\":\"f3e0b9f790f8e8065d59e67b565a83154d9f3079\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b128a30409356df65f1a51cff3eb986cac8cfedc\",\"lessThan\":\"0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b128a30409356df65f1a51cff3eb986cac8cfedc\",\"lessThan\":\"bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b128a30409356df65f1a51cff3eb986cac8cfedc\",\"lessThan\":\"573ac9c70bf7885dc85d82fa44550581bfc3b738\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b128a30409356df65f1a51cff3eb986cac8cfedc\",\"lessThan\":\"80231f069240d52e98b6a317456c67b2eafd0781\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b128a30409356df65f1a51cff3eb986cac8cfedc\",\"lessThan\":\"e01780ea4661172734118d2a5f41bc9720765668\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"kernel/padata.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5.4\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"5.4\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.235\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.179\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.129\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.76\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.13\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.13.2\",\"lessThanOrEqual\":\"6.13.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.14\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]},{\"source\":\"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e\",\"affectedData\":[{\"vendor\":\"Siemens\",\"product\":\"SIMATIC S7-1500 TM MFP - GNU/Linux subsystem\",\"defaultStatus\":\"unknown\",\"versions\":[{\"version\":\"0\",\"lessThan\":\"*\",\"versionType\":\"custom\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2025-02-27T17:58:06.104597Z\",\"id\":\"CVE-2025-21727\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"total\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.4\",\"versionEndExcluding\":\"5.10.235\",\"matchCriteriaId\":\"5FEF389E-870E-4BCB-A3FF-0B8042738CF0\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.179\",\"matchCriteriaId\":\"C708062C-4E1B-465F-AE6D-C09C46400875\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.129\",\"matchCriteriaId\":\"2DA5009C-C9B9-4A1D-9B96-78427E8F232C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.76\",\"matchCriteriaId\":\"A6D70701-9CB6-4222-A957-00A419878993\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.13\",\"matchCriteriaId\":\"2897389C-A8C3-4D69-90F2-E701B3D66373\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13\",\"versionEndExcluding\":\"6.13.2\",\"matchCriteriaId\":\"6D4116B1-1BFD-4F23-BA84-169CC05FC5A3\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html\",\"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://cert-portal.siemens.com/productcert/html/ssa-265688.html\",\"source\":\"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e\"}]}}",
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-29T23:58:18+00:00",
"cve": "CVE-2025-21727",
"id": "CVE-2025-21727",
"initial_release_date": "2025-02-27T00:00:00+00:00",
"product_status:fixed": "2406",
"product_status:known_affected": "22",
"product_status:known_not_affected": "42",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: padata: fix UAF in padata_reorder",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-21727.json",
"version": "3"
},
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html\"}, {\"url\": \"https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html\"}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2025-11-03T19:36:30.604Z\"}}, {\"affected\": [{\"vendor\": \"Siemens\", \"product\": \"SIMATIC S7-1500 TM MFP - GNU/Linux subsystem\", \"versions\": [{\"status\": \"affected\", \"version\": \"0\", \"lessThan\": \"*\", \"versionType\": \"custom\"}], \"defaultStatus\": \"unknown\"}], \"x_adpType\": \"supplier\", \"references\": [{\"url\": \"https://cert-portal.siemens.com/productcert/html/ssa-265688.html\"}], \"providerMetadata\": {\"orgId\": \"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e\", \"shortName\": \"siemens-SADP\", \"dateUpdated\": \"2026-05-12T12:03:30.794Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 7.8, \"attackVector\": \"LOCAL\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"HIGH\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-21727\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-02-27T17:58:06.104597Z\"}}}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-416\", \"description\": \"CWE-416 Use After Free\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-02-27T17:58:07.900Z\"}}], \"cna\": {\"title\": \"padata: fix UAF in padata_reorder\", \"metrics\": [{\"cvssV3_1\": {\"version\": \"3.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\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:L - The vulnerable padata/pcrypt path is driven through local syscalls \\u2014 an AF_ALG socket bound to `pcrypt(...)` submitting aead requests, and the racing teardown via crypto module autoload or the NETLINK_CRYPTO socket. No remote peer can reach or free the padata shell on its own.\\nAC:L - The attacker controls both sides of the race: they flood concurrent pcrypt requests to keep `padata_reorder()` spinning in its loop while triggering instance teardown, and can widen the window with CPU contention and many parallel workers. The commit confirms it reproduces with a stock LTP test (pcrypt_aead01) once the loop is delayed, meaning it is a naturally occurring, repeatable window.\\nPR:L - A basic unprivileged local user can both instantiate and continuously drive pcrypt via AF_ALG (`alg_bind` performs no capability check) and trigger the teardown side, since `crypto_alg_finish_registration()` \\u2192 `crypto_remove_spawns()` destroys the pcrypt instance when an equal-or-higher-priority same-named implementation registers \\u2014 a module autoload reachable from the same unprivileged bind path.\\nUI:N - Exploitation is entirely attacker-driven through socket operations and crypto requests; no victim action, mount, or file open is required.\\nS:U - The use-after-free corrupts kernel slab memory and stays within the kernel\u0027s own security authority; there is no VM, IOMMU, or sandbox boundary crossed.\\nC:H - Reclaiming the freed `struct parallel_data` gives the attacker control of `pd-\u003ereorder_list`, whose per-CPU dereference in `padata_find_next()` becomes an attacker-directed kernel read, and `pd-\u003eps-\u003epinst` is likewise dereferenced \\u2014 yielding disclosure of arbitrary kernel memory.\\nI:H - The same UAF provides write primitives \\u2014 `list_del_init()` unlink on an attacker-controlled reorder list, `++pd-\u003eprocessed` / `pd-\u003ecpu` writes, and most severely `queue_work(pinst-\u003eserial_wq, \u0026pd-\u003ereorder_work)` invoking a function pointer living in freed, sprayable memory, enabling control-flow hijack and privilege escalation.\\nA:H - Even unweaponized, the slab-use-after-free reported by KASAN dereferences freed percpu and workqueue pointers from a kworker context, reliably producing an oops or kernel panic and taking the system down.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"b128a30409356df65f1a51cff3eb986cac8cfedc\", \"lessThan\": \"f78170bee51469734b1a306a74fc5f777bb22ba6\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b128a30409356df65f1a51cff3eb986cac8cfedc\", \"lessThan\": \"f3e0b9f790f8e8065d59e67b565a83154d9f3079\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b128a30409356df65f1a51cff3eb986cac8cfedc\", \"lessThan\": \"0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b128a30409356df65f1a51cff3eb986cac8cfedc\", \"lessThan\": \"bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b128a30409356df65f1a51cff3eb986cac8cfedc\", \"lessThan\": \"573ac9c70bf7885dc85d82fa44550581bfc3b738\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b128a30409356df65f1a51cff3eb986cac8cfedc\", \"lessThan\": \"80231f069240d52e98b6a317456c67b2eafd0781\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b128a30409356df65f1a51cff3eb986cac8cfedc\", \"lessThan\": \"e01780ea4661172734118d2a5f41bc9720765668\", \"versionType\": \"git\"}], \"programFiles\": [\"kernel/padata.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.4\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.4\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"5.10.235\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.10.*\"}, {\"status\": \"unaffected\", \"version\": \"5.15.179\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"6.1.129\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.1.*\"}, {\"status\": \"unaffected\", \"version\": \"6.6.76\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.12.13\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.12.*\"}, {\"status\": \"unaffected\", \"version\": \"6.13.2\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.13.*\"}, {\"status\": \"unaffected\", \"version\": \"6.14\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"kernel/padata.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6\"}, {\"url\": \"https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079\"}, {\"url\": \"https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd\"}, {\"url\": \"https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de\"}, {\"url\": \"https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738\"}, {\"url\": \"https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781\"}, {\"url\": \"https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\npadata: fix UAF in padata_reorder\\n\\nA bug was found when run ltp test:\\n\\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\\n\\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\\nWorkqueue: pdecrypt_parallel padata_parallel_worker\\nCall Trace:\\n\u003cTASK\u003e\\ndump_stack_lvl+0x32/0x50\\nprint_address_description.constprop.0+0x6b/0x3d0\\nprint_report+0xdd/0x2c0\\nkasan_report+0xa5/0xd0\\npadata_find_next+0x29/0x1a0\\npadata_reorder+0x131/0x220\\npadata_parallel_worker+0x3d/0xc0\\nprocess_one_work+0x2ec/0x5a0\\n\\nIf \u0027mdelay(10)\u0027 is added before calling \u0027padata_find_next\u0027 in the\\n\u0027padata_reorder\u0027 function, this issue could be reproduced easily with\\nltp test (pcrypt_aead01).\\n\\nThis can be explained as bellow:\\n\\npcrypt_aead_encrypt\\n...\\npadata_do_parallel\\nrefcount_inc(\u0026pd-\u003erefcnt); // add refcnt\\n...\\npadata_do_serial\\npadata_reorder // pd\\nwhile (1) {\\npadata_find_next(pd, true); // using pd\\nqueue_work_on\\n...\\npadata_serial_worker\\t\\t\\t\\tcrypto_del_alg\\npadata_put_pd_cnt // sub refcnt\\n\\t\\t\\t\\t\\t\\tpadata_free_shell\\n\\t\\t\\t\\t\\t\\tpadata_put_pd(ps-\u003epd);\\n\\t\\t\\t\\t\\t\\t// pd is freed\\n// loop again, but pd is freed\\n// call padata_find_next, UAF\\n}\\n\\nIn the padata_reorder function, when it loops in \u0027while\u0027, if the alg is\\ndeleted, the refcnt may be decreased to 0 before entering\\n\u0027padata_find_next\u0027, which leads to UAF.\\n\\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\\nand always happen under RCU protection, to address this issue, add\\nsynchronize_rcu() in \u0027padata_free_shell\u0027 wait for all _do_serial calls\\nto finish.\\n\\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.10.235\", \"versionStartIncluding\": \"5.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15.179\", \"versionStartIncluding\": \"5.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.1.129\", \"versionStartIncluding\": \"5.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6.76\", \"versionStartIncluding\": \"5.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.12.13\", \"versionStartIncluding\": \"5.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.13.2\", \"versionStartIncluding\": \"5.4\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.14\", \"versionStartIncluding\": \"5.4\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T11:54:00.224Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2025-21727\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-05T11:54:00.224Z\", \"dateReserved\": \"2024-12-29T08:45:45.754Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2025-02-27T02:07:33.501Z\", \"assignerShortName\": \"Linux\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2025-AVI-1135
Vulnerability from certfr_avis - Published: 2025-12-19 - Updated: 2025-12-19
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Ubuntu | Ubuntu | Ubuntu 20.04 ESM et LTS | ||
| Ubuntu | Ubuntu | Ubuntu 14.04 ESM et LTS | ||
| Ubuntu | Ubuntu | Ubuntu 24.04 LTS | ||
| Ubuntu | Ubuntu | Ubuntu 25.04 | ||
| Ubuntu | Ubuntu | Ubuntu 16.04 ESM et LTS | ||
| Ubuntu | Ubuntu | Ubuntu 20.04 LTS | ||
| Ubuntu | Ubuntu | Ubuntu 18.04 ESM et LTS | ||
| Ubuntu | Ubuntu | Ubuntu 25.10 LTS | ||
| Ubuntu | Ubuntu | Ubuntu 22.04 LTS |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 20.04 ESM et LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM et LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 16.04 ESM et LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM et LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.10 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-38453",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38453"
},
{
"name": "CVE-2025-38559",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38559"
},
{
"name": "CVE-2025-40114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40114"
},
{
"name": "CVE-2025-38490",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38490"
},
{
"name": "CVE-2025-38485",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38485"
},
{
"name": "CVE-2025-38509",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38509"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2025-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38579"
},
{
"name": "CVE-2025-22083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22083"
},
{
"name": "CVE-2025-38711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38711"
},
{
"name": "CVE-2025-38487",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38487"
},
{
"name": "CVE-2025-38335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38335"
},
{
"name": "CVE-2023-52854",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52854"
},
{
"name": "CVE-2025-22033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22033"
},
{
"name": "CVE-2025-39728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39728"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-38471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38471"
},
{
"name": "CVE-2025-38520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38520"
},
{
"name": "CVE-2025-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38588"
},
{
"name": "CVE-2025-38561",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38561"
},
{
"name": "CVE-2025-38574",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38574"
},
{
"name": "CVE-2025-22025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22025"
},
{
"name": "CVE-2025-22036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22036"
},
{
"name": "CVE-2024-26896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26896"
},
{
"name": "CVE-2025-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38586"
},
{
"name": "CVE-2025-39757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39757"
},
{
"name": "CVE-2025-38501",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38501"
},
{
"name": "CVE-2025-38474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38474"
},
{
"name": "CVE-2025-22027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22027"
},
{
"name": "CVE-2025-39902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39902"
},
{
"name": "CVE-2025-39772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39772"
},
{
"name": "CVE-2025-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38601"
},
{
"name": "CVE-2025-22040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22040"
},
{
"name": "CVE-2025-39702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39702"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-38645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38645"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-39685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39685"
},
{
"name": "CVE-2025-38660",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38660"
},
{
"name": "CVE-2023-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53034"
},
{
"name": "CVE-2024-26700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26700"
},
{
"name": "CVE-2025-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23138"
},
{
"name": "CVE-2024-56664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56664"
},
{
"name": "CVE-2025-38152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38152"
},
{
"name": "CVE-2025-38624",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38624"
},
{
"name": "CVE-2025-38454",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38454"
},
{
"name": "CVE-2025-38545",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38545"
},
{
"name": "CVE-2025-38534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38534"
},
{
"name": "CVE-2025-22019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22019"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-22021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22021"
},
{
"name": "CVE-2025-38524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38524"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-38573",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38573"
},
{
"name": "CVE-2025-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38595"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-38557",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38557"
},
{
"name": "CVE-2025-22050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22050"
},
{
"name": "CVE-2025-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38578"
},
{
"name": "CVE-2025-38675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38675"
},
{
"name": "CVE-2025-39735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39735"
},
{
"name": "CVE-2025-38646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38646"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2025-38708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38708"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2025-38563",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38563"
},
{
"name": "CVE-2023-52593",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52593"
},
{
"name": "CVE-2025-38517",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38517"
},
{
"name": "CVE-2025-38609",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38609"
},
{
"name": "CVE-2024-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41006"
},
{
"name": "CVE-2025-22095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22095"
},
{
"name": "CVE-2024-35867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35867"
},
{
"name": "CVE-2025-38463",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38463"
},
{
"name": "CVE-2025-38521",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38521"
},
{
"name": "CVE-2025-39709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39709"
},
{
"name": "CVE-2025-39689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39689"
},
{
"name": "CVE-2025-39787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39787"
},
{
"name": "CVE-2025-39920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39920"
},
{
"name": "CVE-2025-38547",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38547"
},
{
"name": "CVE-2025-39731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39731"
},
{
"name": "CVE-2025-38653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38653"
},
{
"name": "CVE-2025-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38571"
},
{
"name": "CVE-2024-58092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58092"
},
{
"name": "CVE-2025-38695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38695"
},
{
"name": "CVE-2025-39749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39749"
},
{
"name": "CVE-2025-38451",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38451"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38456",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38456"
},
{
"name": "CVE-2025-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38538"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-22039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22039"
},
{
"name": "CVE-2025-38565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38565"
},
{
"name": "CVE-2025-37937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37937"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-38706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38706"
},
{
"name": "CVE-2025-38699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38699"
},
{
"name": "CVE-2025-38707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38707"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2025-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38587"
},
{
"name": "CVE-2025-21729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21729"
},
{
"name": "CVE-2025-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38637"
},
{
"name": "CVE-2025-38677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38677"
},
{
"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-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38555"
},
{
"name": "CVE-2025-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38590"
},
{
"name": "CVE-2022-49390",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49390"
},
{
"name": "CVE-2025-38455",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38455"
},
{
"name": "CVE-2025-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39865"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-39675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39675"
},
{
"name": "CVE-2025-38527",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38527"
},
{
"name": "CVE-2025-37958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37958"
},
{
"name": "CVE-2025-38449",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38449"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-21855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21855"
},
{
"name": "CVE-2025-38693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38693"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-38685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38685"
},
{
"name": "CVE-2025-38502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38502"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2025-38648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38648"
},
{
"name": "CVE-2025-38666",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38666"
},
{
"name": "CVE-2025-38482",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38482"
},
{
"name": "CVE-2024-50196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50196"
},
{
"name": "CVE-2025-39823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39823"
},
{
"name": "CVE-2025-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38634"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-39730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39730"
},
{
"name": "CVE-2025-22035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22035"
},
{
"name": "CVE-2023-52650",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52650"
},
{
"name": "CVE-2025-22080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22080"
},
{
"name": "CVE-2025-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38619"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2025-38095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38095"
},
{
"name": "CVE-2025-39737",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39737"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2025-38724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38724"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38582"
},
{
"name": "CVE-2025-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38543"
},
{
"name": "CVE-2025-38698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38698"
},
{
"name": "CVE-2025-38496",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38496"
},
{
"name": "CVE-2021-47385",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47385"
},
{
"name": "CVE-2025-38533",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38533"
},
{
"name": "CVE-2025-38511",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38511"
},
{
"name": "CVE-2025-38537",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38537"
},
{
"name": "CVE-2025-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38546"
},
{
"name": "CVE-2025-39894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39894"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-39743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39743"
},
{
"name": "CVE-2025-40232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40232"
},
{
"name": "CVE-2025-38712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38712"
},
{
"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-38696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38696"
},
{
"name": "CVE-2025-38632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38632"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2025-38558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38558"
},
{
"name": "CVE-2025-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38548"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2024-50006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50006"
},
{
"name": "CVE-2025-38507",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38507"
},
{
"name": "CVE-2025-22028",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22028"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-38438",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38438"
},
{
"name": "CVE-2025-38493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38493"
},
{
"name": "CVE-2025-38670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38670"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2025-38118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38118"
},
{
"name": "CVE-2025-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38602"
},
{
"name": "CVE-2025-38475",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38475"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-22044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22044"
},
{
"name": "CVE-2025-22062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22062"
},
{
"name": "CVE-2025-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38575"
},
{
"name": "CVE-2025-38478",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38478"
},
{
"name": "CVE-2025-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38568"
},
{
"name": "CVE-2025-38240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38240"
},
{
"name": "CVE-2025-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38583"
},
{
"name": "CVE-2025-39788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39788"
},
{
"name": "CVE-2025-22058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22058"
},
{
"name": "CVE-2025-38499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38499"
},
{
"name": "CVE-2025-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22018"
},
{
"name": "CVE-2025-38227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38227"
},
{
"name": "CVE-2025-22056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22056"
},
{
"name": "CVE-2024-49963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49963"
},
{
"name": "CVE-2025-38652",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38652"
},
{
"name": "CVE-2025-38616",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38616"
},
{
"name": "CVE-2025-22057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22057"
},
{
"name": "CVE-2025-38505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38505"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38664"
},
{
"name": "CVE-2025-22068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22068"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2025-38694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38694"
},
{
"name": "CVE-2025-38676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38676"
},
{
"name": "CVE-2025-38530",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38530"
},
{
"name": "CVE-2025-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22045"
},
{
"name": "CVE-2025-38729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38729"
},
{
"name": "CVE-2025-38589",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38589"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2025-38446",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38446"
},
{
"name": "CVE-2025-38593",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38593"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2025-38687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38687"
},
{
"name": "CVE-2025-38529",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38529"
},
{
"name": "CVE-2025-40177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40177"
},
{
"name": "CVE-2023-52574",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52574"
},
{
"name": "CVE-2025-38715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38715"
},
{
"name": "CVE-2025-39734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39734"
},
{
"name": "CVE-2025-22072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22072"
},
{
"name": "CVE-2025-22060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22060"
},
{
"name": "CVE-2025-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38608"
},
{
"name": "CVE-2022-49026",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49026"
},
{
"name": "CVE-2025-38650",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38650"
},
{
"name": "CVE-2025-39710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39710"
},
{
"name": "CVE-2025-37925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37925"
},
{
"name": "CVE-2025-39683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39683"
},
{
"name": "CVE-2025-39794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39794"
},
{
"name": "CVE-2025-38528",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38528"
},
{
"name": "CVE-2025-38468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38468"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2025-22066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22066"
},
{
"name": "CVE-2025-38642",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38642"
},
{
"name": "CVE-2025-38452",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38452"
},
{
"name": "CVE-2025-38713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38713"
},
{
"name": "CVE-2025-38148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38148"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2025-39727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39727"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-38678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38678"
},
{
"name": "CVE-2022-50070",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50070"
},
{
"name": "CVE-2025-38654",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38654"
},
{
"name": "CVE-2025-22047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22047"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2025-22070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22070"
},
{
"name": "CVE-2025-38697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38697"
},
{
"name": "CVE-2025-22071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22071"
},
{
"name": "CVE-2025-38691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38691"
},
{
"name": "CVE-2025-38489",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38489"
},
{
"name": "CVE-2025-39818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39818"
},
{
"name": "CVE-2025-38483",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38483"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-38639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38639"
},
{
"name": "CVE-2025-38628",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38628"
},
{
"name": "CVE-2025-22075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22075"
},
{
"name": "CVE-2025-38612",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38612"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-22065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22065"
},
{
"name": "CVE-2025-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38566"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-38718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38718"
},
{
"name": "CVE-2025-39673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39673"
},
{
"name": "CVE-2025-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38663"
},
{
"name": "CVE-2025-40157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40157"
},
{
"name": "CVE-2025-22097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22097"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2025-39964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39964"
},
{
"name": "CVE-2025-39809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39809"
},
{
"name": "CVE-2025-39993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39993"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2024-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49935"
},
{
"name": "CVE-2025-39703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39703"
},
{
"name": "CVE-2025-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38549"
},
{
"name": "CVE-2025-38665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38665"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2025-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38577"
},
{
"name": "CVE-2025-38671",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38671"
},
{
"name": "CVE-2025-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38635"
},
{
"name": "CVE-2025-22020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22020"
},
{
"name": "CVE-2025-38488",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38488"
},
{
"name": "CVE-2025-38570",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38570"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-38492",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38492"
},
{
"name": "CVE-2025-39766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39766"
},
{
"name": "CVE-2025-39801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39801"
},
{
"name": "CVE-2025-38440",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38440"
},
{
"name": "CVE-2025-39724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39724"
},
{
"name": "CVE-2025-39687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39687"
},
{
"name": "CVE-2025-38510",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38510"
},
{
"name": "CVE-2025-40300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40300"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-38668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38668"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2025-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38615"
},
{
"name": "CVE-2025-39684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39684"
},
{
"name": "CVE-2025-38526",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38526"
},
{
"name": "CVE-2025-38472",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38472"
},
{
"name": "CVE-2025-38506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38506"
},
{
"name": "CVE-2025-38494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38494"
},
{
"name": "CVE-2025-40018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40018"
},
{
"name": "CVE-2024-50061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50061"
},
{
"name": "CVE-2024-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53068"
},
{
"name": "CVE-2024-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53218"
},
{
"name": "CVE-2025-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38604"
},
{
"name": "CVE-2025-38623",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38623"
},
{
"name": "CVE-2025-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38544"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2025-38347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38347"
},
{
"name": "CVE-2025-39776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39776"
},
{
"name": "CVE-2025-37968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37968"
},
{
"name": "CVE-2025-38437",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38437"
},
{
"name": "CVE-2025-38351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38351"
},
{
"name": "CVE-2025-38477",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38477"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2025-39736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39736"
},
{
"name": "CVE-2025-22063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22063"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2024-56767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56767"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-37838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37838"
},
{
"name": "CVE-2025-39742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39742"
},
{
"name": "CVE-2025-38352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38352"
},
{
"name": "CVE-2025-38605",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38605"
},
{
"name": "CVE-2024-36331",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36331"
},
{
"name": "CVE-2025-38655",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38655"
},
{
"name": "CVE-2025-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38610"
},
{
"name": "CVE-2025-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38560"
},
{
"name": "CVE-2025-39725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39725"
},
{
"name": "CVE-2025-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38551"
},
{
"name": "CVE-2025-38701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38701"
},
{
"name": "CVE-2025-38349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38349"
},
{
"name": "CVE-2024-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53112"
},
{
"name": "CVE-2024-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53090"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2025-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38618"
},
{
"name": "CVE-2025-38484",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38484"
},
{
"name": "CVE-2025-38469",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38469"
},
{
"name": "CVE-2025-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38581"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2025-39891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39891"
},
{
"name": "CVE-2025-39790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39790"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2025-38680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38680"
},
{
"name": "CVE-2025-38497",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38497"
},
{
"name": "CVE-2025-38662",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38662"
},
{
"name": "CVE-2025-38684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38684"
},
{
"name": "CVE-2025-38165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38165"
},
{
"name": "CVE-2025-22042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22042"
},
{
"name": "CVE-2025-39686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39686"
},
{
"name": "CVE-2025-39798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39798"
},
{
"name": "CVE-2025-38495",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38495"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-39714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39714"
},
{
"name": "CVE-2025-38567",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38567"
},
{
"name": "CVE-2024-50179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50179"
},
{
"name": "CVE-2025-22038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22038"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38576",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38576"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-38525",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38525"
},
{
"name": "CVE-2025-38629",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38629"
},
{
"name": "CVE-2025-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38553"
},
{
"name": "CVE-2025-39738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39738"
},
{
"name": "CVE-2025-22089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22089"
},
{
"name": "CVE-2024-50067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50067"
},
{
"name": "CVE-2023-53074",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53074"
},
{
"name": "CVE-2025-39713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39713"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38539"
},
{
"name": "CVE-2025-38480",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38480"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2025-38649",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38649"
},
{
"name": "CVE-2025-39946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39946"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2025-38531",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38531"
},
{
"name": "CVE-2025-38450",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38450"
},
{
"name": "CVE-2025-39693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39693"
},
{
"name": "CVE-2025-38503",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38503"
},
{
"name": "CVE-2025-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38630"
},
{
"name": "CVE-2025-38606",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38606"
},
{
"name": "CVE-2025-38481",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38481"
},
{
"name": "CVE-2025-38585",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38585"
},
{
"name": "CVE-2025-38625",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38625"
},
{
"name": "CVE-2025-22054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22054"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2022-50327",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50327"
},
{
"name": "CVE-2025-22086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22086"
},
{
"name": "CVE-2025-39682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39682"
},
{
"name": "CVE-2025-39676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39676"
},
{
"name": "CVE-2025-22073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22073"
},
{
"name": "CVE-2025-38631",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38631"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-39783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39783"
},
{
"name": "CVE-2025-39835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39835"
},
{
"name": "CVE-2025-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38569"
},
{
"name": "CVE-2025-38512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38512"
},
{
"name": "CVE-2025-22064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22064"
},
{
"name": "CVE-2025-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38622"
},
{
"name": "CVE-2025-38700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38700"
},
{
"name": "CVE-2025-38508",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38508"
},
{
"name": "CVE-2025-38532",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38532"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2025-22053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22053"
},
{
"name": "CVE-2023-52935",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52935"
},
{
"name": "CVE-2025-22079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22079"
},
{
"name": "CVE-2025-38640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38640"
},
{
"name": "CVE-2025-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38476"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-22041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22041"
},
{
"name": "CVE-2025-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38572"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38550"
},
{
"name": "CVE-2025-38535",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38535"
},
{
"name": "CVE-2024-47691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47691"
},
{
"name": "CVE-2025-22081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22081"
},
{
"name": "CVE-2025-38473",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38473"
},
{
"name": "CVE-2025-38714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38714"
},
{
"name": "CVE-2025-38470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38470"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
},
{
"name": "CVE-2025-39752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39752"
}
],
"initial_release_date": "2025-12-19T00:00:00",
"last_revision_date": "2025-12-19T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-1135",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-12-19T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7931-2",
"url": "https://ubuntu.com/security/notices/USN-7931-2"
},
{
"published_at": "2025-12-12",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7907-5",
"url": "https://ubuntu.com/security/notices/USN-7907-5"
},
{
"published_at": "2025-12-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7889-7",
"url": "https://ubuntu.com/security/notices/USN-7889-7"
},
{
"published_at": "2025-12-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7938-1",
"url": "https://ubuntu.com/security/notices/USN-7938-1"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7931-1",
"url": "https://ubuntu.com/security/notices/USN-7931-1"
},
{
"published_at": "2025-12-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7937-1",
"url": "https://ubuntu.com/security/notices/USN-7937-1"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7920-2",
"url": "https://ubuntu.com/security/notices/USN-7920-2"
},
{
"published_at": "2025-12-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7939-2",
"url": "https://ubuntu.com/security/notices/USN-7939-2"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7935-1",
"url": "https://ubuntu.com/security/notices/USN-7935-1"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7931-3",
"url": "https://ubuntu.com/security/notices/USN-7931-3"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7909-5",
"url": "https://ubuntu.com/security/notices/USN-7909-5"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7934-1",
"url": "https://ubuntu.com/security/notices/USN-7934-1"
},
{
"published_at": "2025-12-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7939-1",
"url": "https://ubuntu.com/security/notices/USN-7939-1"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7933-1",
"url": "https://ubuntu.com/security/notices/USN-7933-1"
},
{
"published_at": "2025-12-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7936-1",
"url": "https://ubuntu.com/security/notices/USN-7936-1"
},
{
"published_at": "2025-12-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7940-1",
"url": "https://ubuntu.com/security/notices/USN-7940-1"
}
]
}
FKIE_CVE-2025-21727
Vulnerability from fkie_nvd - Published: 2025-02-27 02:15 - Updated: 2026-06-17 08:44| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html | ||
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html | ||
| 0b142b55-0307-4c5a-b3c9-f314f3fb7c5e | https://cert-portal.siemens.com/productcert/html/ssa-265688.html |
| Vendor | Product | Version | |
|---|---|---|---|
| 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": [
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f78170bee51469734b1a306a74fc5f777bb22ba6",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "f3e0b9f790f8e8065d59e67b565a83154d9f3079",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "573ac9c70bf7885dc85d82fa44550581bfc3b738",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "80231f069240d52e98b6a317456c67b2eafd0781",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
},
{
"lessThan": "e01780ea4661172734118d2a5f41bc9720765668",
"status": "affected",
"version": "b128a30409356df65f1a51cff3eb986cac8cfedc",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.4"
},
{
"lessThan": "5.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.129",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.76",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5FEF389E-870E-4BCB-A3FF-0B8042738CF0",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C708062C-4E1B-465F-AE6D-C09C46400875",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2DA5009C-C9B9-4A1D-9B96-78427E8F232C",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A6D70701-9CB6-4222-A957-00A419878993",
"versionEndExcluding": "6.6.76",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2897389C-A8C3-4D69-90F2-E701B3D66373",
"versionEndExcluding": "6.12.13",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6D4116B1-1BFD-4F23-BA84-169CC05FC5A3",
"versionEndExcluding": "6.13.2",
"versionStartIncluding": "6.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0027mdelay(10)\u0027 is added before calling \u0027padata_find_next\u0027 in the\n\u0027padata_reorder\u0027 function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026pd-\u003erefcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u003epd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0027while\u0027, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0027padata_find_next\u0027, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0027padata_free_shell\u0027 wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: correcci\u00f3n de UAF en padata_reorder Se encontr\u00f3 un error al ejecutar la prueba ltp: ERROR: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If \u0027mdelay(10)\u0027 is added before calling \u0027padata_find_next\u0027 in the \u0027padata_reorder\u0027 function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps-\u0026gt;pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } En la funci\u00f3n padata_reorder, cuando se repite en \u0027while\u0027, si se elimina el alg, el refcnt puede disminuirse a 0 antes de ingresar a \u0027padata_find_next\u0027, lo que lleva a UAF. Como se mencion\u00f3 en [1], se supone que do_serial se debe llamar con los BH deshabilitados y siempre ocurre bajo la protecci\u00f3n de RCU, para abordar este problema, agreguesynchronous_rcu() en \u0027padata_free_shell\u0027 y espere a que finalicen todas las llamadas a _do_serial. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/"
}
],
"id": "CVE-2025-21727",
"lastModified": "2026-06-17T08:44:08.047",
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-21727",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:58:06.104597Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-02-27T02:15:16.423",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-WVMF-XH97-GMFR
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/
{
"affected": [],
"aliases": [
"CVE-2025-21727"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T02:15:16Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0027mdelay(10)\u0027 is added before calling \u0027padata_find_next\u0027 in the\n\u0027padata_reorder\u0027 function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026pd-\u003erefcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u003epd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0027while\u0027, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0027padata_find_next\u0027, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0027padata_free_shell\u0027 wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/",
"id": "GHSA-wvmf-xh97-gmfr",
"modified": "2026-05-12T15:30:46Z",
"published": "2025-02-27T03:34:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-24-102-01
Vulnerability from csaf_cisa - Published: 2024-04-09 00:00 - Updated: 2026-05-14 06:00MSRC_CVE-2025-21727
Vulnerability from csaf_microsoft - Published: 2025-02-02 00:00 - Updated: 2026-02-18 01:08oesa-2025-1339
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
dma-debug: fix a possible deadlock on radix_lock
radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock():
CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock()
CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd().
CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends).
To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap().(CVE-2024-47143)
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix possible lkb_resource null dereference
This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded.
The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference.
In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.(CVE-2024-47809)
In the Linux kernel, the following vulnerability has been resolved:
bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again
Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cache_set_flush().
1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache);
>From the above code in cache_set_flush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. __bch_btree_node_alloc() never returns NULL but c->root is possible to be NULL at above line 1721.
This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Properly hide first-in-list PCIe extended capability
There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user.
Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden.
The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list.
However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array.
Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array.
Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before).
[1]
WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:
net: af_can: do not leave a dangling sk pointer in can_create()
On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: avoid erroring out after sock_init_data() in packet_create()
After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Hold module reference while requesting a module
User space may unload ip_set.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in cleanup_bearer().
[0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830
[1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid potential out-of-bound access in fill_frame_info()
syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one.
Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case.
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL.
E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash
This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash.
If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect.
So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb.
Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68(CVE-2024-56670)
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
Dominique: remove confusing variable reset to 0
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level
cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to restrict this maximum depth to a more reasonable value not to harm performance. Remove unnecessary WARN_ON_ONCE which is reachable from userspace.(CVE-2024-56783)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a
Fix the dtc warnings:
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'
And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"):
WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0
The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a).(CVE-2024-56785)
In the Linux kernel, the following vulnerability has been resolved:
s390/entry: Mark IRQ entries to fix stack depot warnings
The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot.
Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved.
While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific.
Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like:
Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8
with PREEMPT and KASAN enabled.
Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section.
This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value.
SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing.
IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies.(CVE-2024-57838)
In the Linux kernel, the following vulnerability has been resolved:
drm/dp_mst: Fix resetting msg rx state after topology removal
If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with the reading/parsing of the message from another thread via drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").
Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drm_dp_mst_topology_mgr::lock for the whole duration of the message reception/parsing in drm_dp_mst_handle_down_rep() and drm_dp_mst_handle_up_req(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)
In the Linux kernel, the following vulnerability has been resolved:
rdma/cxgb4: Prevent potential integer overflow on 32bit
The "gl->tot_len" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an integer wrapping bug. Use size_add() to prevent this.(CVE-2024-57973)
In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Fix potential error pointer dereference in detach_pm()
The proble is on the first line:
if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i]))
If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.(CVE-2024-57978)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections
A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop in hid_apply_multiplier."), but the other has not been fixed.
This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying:
* "The Resolution Multiplier control must be contained in the same
* Logical Collection as the control(s) to which it is to be applied.
...
* If no Logical Collection is
* defined, the Resolution Multiplier is associated with all
* controls in the report."
* HID Usage Table, v1.12, Section 4.3.1, p30
*
* Thus, search from the current collection upwards until we find a
* logical collection...
The comment and the code overlook the possibility that none of the collections found may be a Logical Collection.
The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.(CVE-2024-57986)
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check
syzbot has found a type mismatch between a USB pipe and the transfer endpoint, which is triggered by the hid-thrustmaster driver[1]. There is a number of similar, already fixed issues [2]. In this case as in others, implementing check for endpoint type fixes the issue.
[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470 [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: fix channel survey memory allocation size
KASAN reported a memory allocation issue in wcn->chan_survey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chan_survey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel.(CVE-2024-57997)
In the Linux kernel, the following vulnerability has been resolved:
OPP: add index check to assert to avoid buffer overflow in _read_freq()
Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: dev_pm_opp_find_freq_exact_indexed() or dev_pm_opp_find_freq_ceil/floor_indexed().
Add a secondary parameter to the assert function, unused for assert_single_clk() then add assert_clk_index() which will check for the clock index when called from the _indexed() find functions.(CVE-2024-57998)
In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()
In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.
This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host).
This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.
If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar.
While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
ipmi: ipmb: Add check devm_kasprintf() returned value
devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.(CVE-2024-58051)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table
The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix handling of received connection abort
Fix the handling of a connection abort that we've received. Though the abort is at the connection level, it needs propagating to the calls on that connection. Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang.
Also add some tracing for the logging of connection aborts.(CVE-2024-58053)
In the Linux kernel, the following vulnerability has been resolved:
staging: media: max96712: fix kernel oops when removing module
The following kernel oops is thrown when trying to remove the max96712 module:
Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2 imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse [last unloaded: imx8_isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr : v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: led_put+0x1c/0x40 v4l2_subdev_put_privacy_led+0x48/0x58 v4l2_async_unregister_subdev+0x2c/0x1a4 max96712_remove+0x1c/0x38 [max96712] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x4c/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 max96712_i2c_driver_exit+0x18/0x1d0 [max96712] __arm64_sys_delete_module+0x1a4/0x290 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]---
This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2_async_unregister_subdev(), leading to a crash.(CVE-2024-58054)
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Fix ida_free call while not allocated
In the rproc_alloc() function, on error, put_device(&rproc->dev) is called, leading to the call of the rproc_type_release() function. An error can occurs before ida_alloc is called.
In such case in rproc_type_release(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. ida_free() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] ida_free called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: events_unbound deferred_probe_work_func [ 4.242504] Call trace: [ 4.242522] unwind_backtrace from show_stack+0x10/0x14 [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64 [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188 [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164 [ 4.270565] ida_free from rproc_type_release+0x38/0x60 [ 4.275832] rproc_type_release from device_release+0x30/0xa0 [ 4.281601] device_release from kobject_put+0xc4/0x294 [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4 [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc] [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc
Calling ida_alloc earlier in rproc_alloc ensures that the rproc->index is properly set.(CVE-2024-58056)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: skip dumping tnc tree when zroot is null
Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.(CVE-2024-58058)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: prohibit deactivating all links
In the internal API this calls this is a WARN_ON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly.(CVE-2024-58061)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: fix memory leaks and invalid access at probe error path
Deinitialize at reverse order when probe fails.
When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue.
And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked.
Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").(CVE-2024-58063)
In the Linux kernel, the following vulnerability has been resolved:
OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized
If a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : _read_bw+0x8/0x10 lr : _opp_table_find_key+0x9c/0x174 ... Call trace: _read_bw+0x8/0x10 (P) _opp_table_find_key+0x9c/0x174 (L) _find_key+0x98/0x168 dev_pm_opp_find_bw_ceil+0x50/0x88 ...
In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with _read_bw().(CVE-2024-58068)
In the Linux kernel, the following vulnerability has been resolved:
team: prevent adding a device which is already a team device lower
Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.
This is not useful in practice and can lead to recursive locking:
$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0
============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
lock(team->team_lock_key); lock(team->team_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by ip/7684:
stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: remove unused check_buddy_priv
Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures.
Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device.
However, that function was never used.
Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory.
Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.(CVE-2024-58072)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: handle fastopen disconnect correctly
Syzbot was able to trigger a data stream corruption:
WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493 release_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703 mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:726 _syssendmsg+0x52a/0x7e0 net/socket.c:2583 _sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 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 RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 </TASK>
The root cause is the bad handling of disconnect() generated internally by the MPTCP protocol in case of connect FASTOPEN errors.
Address the issue increasing the socket disconnect counter even on such a case, to allow other threads waiting on the same socket lock to properly error out.(CVE-2025-21705)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: consolidate suboption status
MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info.
Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption.
The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized:
BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
---truncated---(CVE-2025-21707)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: rtl8150: enable basic endpoint checking
Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.
For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...
This change has not been tested on real hardware.(CVE-2025-21708)
In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.
However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.
The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.
The following excerpt of a logging session, with own comments added, shows more in detail what is happening:
// tcp_v4_rcv(->) // tcp_rcv_established(->) 5201<->39222: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
5201<->39222: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0]
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
5201<->39222: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0
5201<->39222: ADVERTISING WIN 0, ACK_SEQ: 265600160
// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: new_win = 0, win_now = 131184, 2 * win_now = 262368: new_win >= (2 * win_now) ? --> time_to_ack = 0: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
[copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
returning 6104 bytes
// After each read, the algorithm for calculating the new receive // window in __tcp_cleanup_rbuf() finds it is too small to advertise // or to update tp->rcv_wnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: [new_win = 262144, win_now = 131184, 2 * win_n ---truncated---(CVE-2025-21710)
In the Linux kernel, the following vulnerability has been resolved:
net/rose: prevent integer overflows in rose_setsockopt()
In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur.
Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.(CVE-2025-21711)
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.
This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool.(CVE-2025-21715)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix uninit-value in vxlan_vnifilter_dump()
KMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].
If the length of the netlink message payload is less than sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes beyond the message. This can lead to uninit-value access. Fix this by returning an error in such situations.
[1] BUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786 netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317 __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432 netlink_dump_start include/linux/netlink.h:340 [inline] rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline] rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882 netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542 rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 _syssendmsg+0x7f4/0xb50 net/socket.c:2583 _sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4110 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205 kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196 netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 _syssendmsg+0x7f4/0xb50 net/socket.c:2583 _sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete intermediate secpath entry in packet offload mode
Packets handled by hardware have added secpath as a way to inform XFRM core code that this path was already handled. That secpath is not needed at all after policy is checked and it is removed later in the stack.
However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward), that secpath is not removed and packets which already were handled are reentered to the driver TX path with xfrm_offload set.
The following kernel panic is observed in mlx5 in such case:
mlx5_core 0000:04:00.0 enp4s0f0np0: Link up mlx5_core 0000:04:00.1 enp4s0f1np1: Link up Initializing XFRM netlink socket IPsec XFRM device driver BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: Oops: 0010 [#1] PREEMPT SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffb87380003800 EFLAGS: 00010206 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? show_regs+0x63/0x70 ? __die_body+0x20/0x60 ? __die+0x2b/0x40 ? page_fault_oops+0x15c/0x550 ? do_user_addr_fault+0x3ed/0x870 ? exc_page_fault+0x7f/0x190 ? asm_exc_page_fault+0x27/0x30 mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core] mlx5e_xmit+0x58e/0x1980 [mlx5_core] ? __fib_lookup+0x6a/0xb0 dev_hard_start_xmit+0x82/0x1d0 sch_direct_xmit+0xfe/0x390 __dev_queue_xmit+0x6d8/0xee0 ? __fib_lookup+0x6a/0xb0 ? internal_add_timer+0x48/0x70 ? mod_timer+0xe2/0x2b0 neigh_resolve_output+0x115/0x1b0 __neigh_update+0x26a/0xc50 neigh_update+0x14/0x20 arp_process+0x2cb/0x8e0 ? __napi_build_skb+0x5e/0x70 arp_rcv+0x11e/0x1c0 ? dev_gro_receive+0x574/0x820 __netif_receive_skb_list_core+0x1cf/0x1f0 netif_receive_skb_list_internal+0x183/0x2a0 napi_complete_done+0x76/0x1c0 mlx5e_napi_poll+0x234/0x7a0 [mlx5_core] __napi_poll+0x2d/0x1f0 net_rx_action+0x1a6/0x370 ? atomic_notifier_call_chain+0x3b/0x50 ? irq_int_handler+0x15/0x20 [mlx5_core] handle_softirqs+0xb9/0x2f0 ? handle_irq_event+0x44/0x60 irq_exit_rcu+0xdb/0x100 common_interrupt+0x98/0xc0 </IRQ> <TASK> asm_common_interrupt+0x27/0x40 RIP: 0010:pv_native_safe_halt+0xb/0x10 Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb 40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8 RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680 RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4 RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70 R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8 ? default_idle+0x9/0x20 arch_cpu_idle+0x9/0x10 default_idle_call+0x29/0xf0 do_idle+0x1f2/0x240 cpu_startup_entry+0x2c/0x30 rest_init+0xe7/0x100 start_kernel+0x76b/0xb90 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xc0/0x110 ? setup_ghcb+0xe/0x130 common_startup_64+0x13e/0x141 </TASK> Modules linked in: esp4_offload esp4 xfrm_interface xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf ---truncated---(CVE-2025-21720)
In the Linux kernel, the following vulnerability has been resolved:
iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()
Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index() where shifting the constant "1" (of type int) by bitmap->mapped.pgshift (an unsigned long value) could result in undefined behavior.
The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds 31 (e.g., pgshift = 63) the shift operation overflows, as the result cannot be represented in a 32-bit type.
To resolve this, the constant is updated to "1UL", promoting it to an unsigned long type to match the operand's type.(CVE-2025-21724)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix oops due to unset link speed
It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always be set by the server, so the client must handle any values and then prevent oopses like below from happening:
Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8 e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89 c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24 RSP: 0018:ffffc90001817be0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99 RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228 RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200 R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58 FS: 00007fe27119e740(0000) GS:ffff888148600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0x159/0x1b0 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? do_error_trap+0x90/0x130 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? exc_divide_error+0x39/0x50 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? asm_exc_divide_error+0x1a/0x20 ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs] ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? seq_read_iter+0x42e/0x790 seq_read_iter+0x19a/0x790 proc_reg_read_iter+0xbe/0x110 ? __pfx_proc_reg_read_iter+0x10/0x10 vfs_read+0x469/0x570 ? do_user_addr_fault+0x398/0x760 ? __pfx_vfs_read+0x10/0x10 ? find_held_lock+0x8a/0xa0 ? __pfx_lock_release+0x10/0x10 ksys_read+0xd3/0x170 ? __pfx_ksys_read+0x10/0x10 ? __rcu_read_unlock+0x50/0x270 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe271288911 Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911 RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003 RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000 </TASK>
Fix this by setting cifs_server_iface::speed to a sane value (1Gbps) by default when link speed is unset.(CVE-2025-21725)
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:
crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context> invoke_padata_reorder // UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.(CVE-2025-21726)
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Send signals asynchronously if !preemptible
BPF programs can execute in all kinds of contexts and when a program
running in a non-preemptible context uses the bpf_send_signal() kfunc,
it will cause issues because this kfunc can sleep.
Change irqs_disabled() to !preemptible().(CVE-2025-21728)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix class @block_class's subsystem refcount leakage
blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage.
Fix by ending the iterating with class_dev_iter_exit().(CVE-2025-21745)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()
When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid.
There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns()
At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value.
Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning.
The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().(CVE-2025-21799)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix warnings during S3 suspend
The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(), and the later one may call the preempt_schedule_common() function, resulting in a thread switch and causing the CPU to be in an interrupt enabled state after the enable_gpe_wakeup() function returns, leading to the warnings as follow.
[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]---
The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Since there is no longer concurrent execution during loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes() directly in enable_gpe_wakeup().
The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep()").(CVE-2025-21803)
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.
Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:
$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:
$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3
In the Linux kernel, the following vulnerability has been resolved:
net: let net.core.dev_weight always be non-zero
The following problem was encountered during stability test:
(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1
This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue.
Making the napi's weight always non-zero solves this problem.
Triggering this issue requires system-wide admin (setting is not namespaced).(CVE-2025-21806)
In the Linux kernel, the following vulnerability has been resolved:
net: xdp: Disallow attaching device-bound programs in generic mode
Device-bound programs are used to support RX metadata kfuncs. These kfuncs are driver-specific and rely on the driver context to read the metadata. This means they can't work in generic XDP mode. However, there is no check to disallow such programs from being attached in generic mode, in which case the metadata kfuncs will be called in an invalid context, leading to crashes.
Fix this by adding a check to disallow attaching device-bound programs in generic mode.(CVE-2025-21808)
In the Linux kernel, the following vulnerability has been resolved:
driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()
There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage:
// All members of @iter are wild pointers. struct class_dev_iter iter;
// class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...);
// Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... };
// Also dereference these wild pointers here. class_dev_iter_exit(&iter);
Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next().(CVE-2025-21810)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: protect access to buffers with no active references
nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages.
For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers().
Eliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)
In the Linux kernel, the following vulnerability has been resolved:
ax25: rcu protect dev->ax25_ptr
syzbot found a lockdep issue [1].
We should remove ax25 RTNL dependency in ax25_setsockopt()
This should also fix a variety of possible UAF in ax25.
[1]
WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted
syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 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
-> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 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
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex);
*** DEADLOCK ***
1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---(CVE-2025-21812)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't flush non-uploaded STAs
If STA state is pre-moved to AUTHORIZED (such as in IBSS scenarios) and insertion fails, the station is freed. In this case, the driver never knew about the station, so trying to flush it is unexpected and may crash.
Check if the sta was uploaded to the driver before and fix this.(CVE-2025-21828)
In the Linux kernel, the following vulnerability has been resolved:
bpf: avoid holding freeze_mutex during mmap operation
We use map->freeze_mutex to prevent races between map_freeze() and memory mapping BPF map contents with writable permissions. The way we naively do this means we'll hold freeze_mutex for entire duration of all the mm and VMA manipulations, which is completely unnecessary. This can potentially also lead to deadlocks, as reported by syzbot in [0].
So, instead, hold freeze_mutex only during writeability checks, bump (proactively) "write active" count for the map, unlock the mutex and proceed with mmap logic. And only if something went wrong during mmap logic, then undo that "write active" counter increment.
[0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-source-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"perf-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"python3-perf-6.6.0-84.0.0.78.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-84.0.0.78.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-84.0.0.78.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-source-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"perf-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"python3-perf-6.6.0-84.0.0.78.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-84.0.0.78.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-84.0.0.78.oe2403"
}
],
"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\ndma-debug: fix a possible deadlock on radix_lock\n\nradix_lock() shouldn\u0026apos;t be held while holding dma_hash_entry[idx].lock\notherwise, there\u0026apos;s a possible deadlock scenario when\ndma debug API is called holding rq_lock():\n\nCPU0 CPU1 CPU2\ndma_free_attrs()\ncheck_unmap() add_dma_entry() __schedule() //out\n (A) rq_lock()\nget_hash_bucket()\n(A) dma_entry_hash\n check_sync()\n (A) radix_lock() (W) dma_entry_hash\ndma_entry_free()\n(W) radix_lock()\n // CPU2\u0026apos;s one\n (W) rq_lock()\n\nCPU1 situation can happen when it extending radix tree and\nit tries to wake up kswapd via wake_all_kswapd().\n\nCPU2 situation can happen while perf_event_task_sched_out()\n(i.e. dma sync operation is called while deleting perf_event using\n etm and etr tmc which are Arm Coresight hwtracing driver backends).\n\nTo remove this possible situation, call dma_entry_free() after\nput_hash_bucket() in check_unmap().(CVE-2024-47143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: fix possible lkb_resource null dereference\n\nThis patch fixes a possible null pointer dereference when this function is\ncalled from request_lock() as lkb-\u0026gt;lkb_resource is not assigned yet,\nonly after validate_lock_args() by calling attach_lkb(). Another issue\nis that a resource name could be a non printable bytearray and we cannot\nassume to be ASCII coded.\n\nThe log functionality is probably never being hit when DLM is used in\nnormal way and no debug logging is enabled. The null pointer dereference\ncan only occur on a new created lkb that does not have the resource\nassigned yet, it probably never hits the null pointer dereference but we\nshould be sure that other changes might not change this behaviour and we\nactually can hit the mentioned null pointer dereference.\n\nIn this patch we just drop the printout of the resource name, the lkb id\nis enough to make a possible connection to a resource name if this\nexists.(CVE-2024-47809)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: revert replacing IS_ERR_OR_NULL with IS_ERR again\n\nCommit 028ddcac477b (\u0026quot;bcache: Remove unnecessary NULL point check in\nnode allocations\u0026quot;) leads a NULL pointer deference in cache_set_flush().\n\n1721 if (!IS_ERR_OR_NULL(c-\u0026gt;root))\n1722 list_add(\u0026amp;c-\u0026gt;root-\u0026gt;list, \u0026amp;c-\u0026gt;btree_cache);\n\n\u0026gt;From the above code in cache_set_flush(), if previous registration code\nfails before allocating c-\u0026gt;root, it is possible c-\u0026gt;root is NULL as what\nit is initialized. __bch_btree_node_alloc() never returns NULL but\nc-\u0026gt;root is possible to be NULL at above line 1721.\n\nThis patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: Properly hide first-in-list PCIe extended capability\n\nThere are cases where a PCIe extended capability should be hidden from\nthe user. For example, an unknown capability (i.e., capability with ID\ngreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally\nchosen to be hidden from the user.\n\nHiding a capability is done by virtualizing and modifying the \u0026apos;Next\nCapability Offset\u0026apos; field of the previous capability so it points to the\ncapability after the one that should be hidden.\n\nThe special case where the first capability in the list should be hidden\nis handled differently because there is no previous capability that can\nbe modified. In this case, the capability ID and version are zeroed\nwhile leaving the next pointer intact. This hides the capability and\nleaves an anchor for the rest of the capability list.\n\nHowever, today, hiding the first capability in the list is not done\nproperly if the capability is unknown, as struct\nvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID during\ninitialization but the capability ID is not properly checked later when\nused in vfio_config_do_rw(). This leads to the following warning [1] and\nto an out-of-bounds access to ecap_perms array.\n\nFix it by checking cap_id in vfio_config_do_rw(), and if it is greater\nthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct\nread only access instead of the ecap_perms array.\n\nNote that this is safe since the above is the only case where cap_id can\nexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which\nare already checked before).\n\n[1]\n\nWARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\nCPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1\n(snip)\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x69/0x80\n ? __warn+0x8d/0x140\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? report_bug+0x18f/0x1a0\n ? handle_bug+0x63/0xa0\n ? exc_invalid_op+0x19/0x70\n ? asm_exc_invalid_op+0x1b/0x20\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]\n vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]\n vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]\n vfio_device_fops_read+0x27/0x40 [vfio]\n vfs_read+0xbd/0x340\n ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]\n ? __rseq_handle_notify_resume+0xa4/0x4b0\n __x64_sys_pread64+0x96/0xc0\n x64_sys_call+0x1c3d/0x20d0\n do_syscall_64+0x4d/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_can: do not leave a dangling sk pointer in can_create()\n\nOn error can_create() frees the allocated sk object, but sock_init_data()\nhas already attached it to the provided sock object. This will leave a\ndangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: avoid erroring out after sock_init_data() in packet_create()\n\nAfter sock_init_data() the allocated sk object is attached to the provided\nsock object. On error, packet_create() frees the sk object leaving the\ndangling pointer in the sock object on return. Some other code may try\nto use this pointer and cause use-after-free.(CVE-2024-56606)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Hold module reference while requesting a module\n\nUser space may unload ip_set.ko while it is itself requesting a set type\nbackend module, leading to a kernel crash. The race condition may be\nprovoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count. However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n sk_alloc+0x438/0x608\n inet_create+0x4c8/0xcb0\n __sock_create+0x350/0x6b8\n sock_create_kern+0x58/0x78\n udp_sock_create4+0x68/0x398\n udp_sock_create+0x88/0xc8\n tipc_udp_enable+0x5e8/0x848\n __tipc_nl_bearer_enable+0x84c/0xed8\n tipc_nl_bearer_enable+0x38/0x60\n genl_family_rcv_msg_doit+0x170/0x248\n genl_rcv_msg+0x400/0x5b0\n netlink_rcv_skb+0x1dc/0x398\n genl_rcv+0x44/0x68\n netlink_unicast+0x678/0x8b0\n netlink_sendmsg+0x5e4/0x898\n ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3146 [inline]\n packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4091 [inline]\n slab_alloc_node mm/slub.c:4134 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n packet_snd net/packet/af_packet.c:3089 [inline]\n packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer\n\nConsidering that in some extreme cases,\nwhen u_serial driver is accessed by multiple threads,\nThread A is executing the open operation and calling the gs_open,\nThread B is executing the disconnect operation and calling the\ngserial_disconnect function,The port-\u0026gt;port_usb pointer will be set to NULL.\n\nE.g.\n Thread A Thread B\n gs_open() gadget_unbind_driver()\n gs_start_io() composite_disconnect()\n gs_start_rx() gserial_disconnect()\n ... ...\n spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n status = usb_ep_queue() spin_lock(\u0026amp;port-\u0026gt;port_lock)\n spin_lock(\u0026amp;port-\u0026gt;port_lock) port-\u0026gt;port_usb = NULL\n gs_free_requests(port-\u0026gt;port_usb-\u0026gt;in) spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n Crash\n\nThis causes thread A to access a null pointer (port-\u0026gt;port_usb is null)\nwhen calling the gs_free_requests function, causing a crash.\n\nIf port_usb is NULL, the release request will be skipped as it\nwill be done by gserial_disconnect.\n\nSo add a null pointer check to gs_start_io before attempting\nto access the value of the pointer port-\u0026gt;port_usb.\n\nCall trace:\n gs_start_io+0x164/0x25c\n gs_open+0x108/0x13c\n tty_open+0x314/0x638\n chrdev_open+0x1b8/0x258\n do_dentry_open+0x2c4/0x700\n vfs_open+0x2c/0x3c\n path_openat+0xa64/0xc60\n do_filp_open+0xb8/0x164\n do_sys_openat2+0x84/0xf0\n __arm64_sys_openat+0x70/0x9c\n invoke_syscall+0x58/0x114\n el0_svc_common+0x80/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x38/0x68(CVE-2024-56670)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level\n\ncgroup maximum depth is INT_MAX by default, there is a cgroup toggle to\nrestrict this maximum depth to a more reasonable value not to harm\nperformance. Remove unnecessary WARN_ON_ONCE which is reachable from\nuserspace.(CVE-2024-56783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a\n\nFix the dtc warnings:\n\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite \u0026apos;interrupt_provider\u0026apos;\n\nAnd a runtime warning introduced in commit 045b14ca5c36 (\u0026quot;of: WARN on\ndeprecated #address-cells/#size-cells handling\u0026quot;):\n\n WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0\n Missing \u0026apos;#address-cells\u0026apos; in /bus@10000000/pci@1a000000/pci_bridge@9,0\n\nThe fix is similar to commit d89a415ff8d5 (\u0026quot;MIPS: Loongson64: DTS: Fix PCIe\nport nodes for ls7a\u0026quot;), which has fixed the issue for ls2k (despite its\nsubject mentions ls7a).(CVE-2024-56785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/entry: Mark IRQ entries to fix stack depot warnings\n\nThe stack depot filters out everything outside of the top interrupt\ncontext as an uninteresting or irrelevant part of the stack traces. This\nhelps with stack trace de-duplication, avoiding an explosion of saved\nstack traces that share the same IRQ context code path but originate\nfrom different randomly interrupted points, eventually exhausting the\nstack depot.\n\nFiltering uses in_irqentry_text() to identify functions within the\n.irqentry.text and .softirqentry.text sections, which then become the\nlast stack trace entries being saved.\n\nWhile __do_softirq() is placed into the .softirqentry.text section by\ncommon code, populating .irqentry.text is architecture-specific.\n\nCurrently, the .irqentry.text section on s390 is empty, which prevents\nstack depot filtering and de-duplication and could result in warnings\nlike:\n\nStack depot reached limit capacity\nWARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8\n\nwith PREEMPT and KASAN enabled.\n\nFix this by moving the IO/EXT interrupt handlers from .kprobes.text into\nthe .irqentry.text section and updating the kprobes blacklist to include\nthe .irqentry.text section.\n\nThis is done only for asynchronous interrupts and explicitly not for\nprogram checks, which are synchronous and where the context beyond the\nprogram check is important to preserve. Despite machine checks being\nsomewhat in between, they are extremely rare, and preserving context\nwhen possible is also of value.\n\nSVCs and Restart Interrupts are not relevant, one being always at the\nboundary to user space and the other being a one-time thing.\n\nIRQ entries filtering is also optionally used in ftrace function graph,\nwhere the same logic applies.(CVE-2024-57838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn\u0026apos;t hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 (\u0026quot;drm/dp_mst: Fix MST\nsideband message body length check\u0026quot;).\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.(CVE-2024-57876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrdma/cxgb4: Prevent potential integer overflow on 32bit\n\nThe \u0026quot;gl-\u0026gt;tot_len\u0026quot; variable is controlled by the user. It comes from\nprocess_responses(). On 32bit systems, the \u0026quot;gl-\u0026gt;tot_len + sizeof(struct\ncpl_pass_accept_req) + sizeof(struct rss_header)\u0026quot; addition could have an\ninteger wrapping bug. Use size_add() to prevent this.(CVE-2024-57973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imx-jpeg: Fix potential error pointer dereference in detach_pm()\n\nThe proble is on the first line:\n\n\tif (jpeg-\u0026gt;pd_dev[i] \u0026amp;\u0026amp; !pm_runtime_suspended(jpeg-\u0026gt;pd_dev[i]))\n\nIf jpeg-\u0026gt;pd_dev[i] is an error pointer, then passing it to\npm_runtime_suspended() will lead to an Oops. The other conditions\ncheck for both error pointers and NULL, but it would be more clear to\nuse the IS_ERR_OR_NULL() check for that.(CVE-2024-57978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Fix assumption that Resolution Multipliers must be in Logical Collections\n\nA report in 2019 by the syzbot fuzzer was found to be connected to two\nerrors in the HID core associated with Resolution Multipliers. One of\nthe errors was fixed by commit ea427a222d8b (\u0026quot;HID: core: Fix deadloop\nin hid_apply_multiplier.\u0026quot;), but the other has not been fixed.\n\nThis error arises because hid_apply_multipler() assumes that every\nResolution Multiplier control is contained in a Logical Collection,\ni.e., there\u0026apos;s no way the routine can ever set multiplier_collection to\nNULL. This is in spite of the fact that the function starts with a\nbig comment saying:\n\n\t * \u0026quot;The Resolution Multiplier control must be contained in the same\n\t * Logical Collection as the control(s) to which it is to be applied.\n\t ...\n\t * If no Logical Collection is\n\t * defined, the Resolution Multiplier is associated with all\n\t * controls in the report.\u0026quot;\n\t * HID Usage Table, v1.12, Section 4.3.1, p30\n\t *\n\t * Thus, search from the current collection upwards until we find a\n\t * logical collection...\n\nThe comment and the code overlook the possibility that none of the\ncollections found may be a Logical Collection.\n\nThe fix is to set the multiplier_collection pointer to NULL if the\ncollection found isn\u0026apos;t a Logical Collection.(CVE-2024-57986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check\n\nsyzbot has found a type mismatch between a USB pipe and the transfer\nendpoint, which is triggered by the hid-thrustmaster driver[1].\nThere is a number of similar, already fixed issues [2].\nIn this case as in others, implementing check for endpoint type fixes the issue.\n\n[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470\n[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wcn36xx: fix channel survey memory allocation size\n\nKASAN reported a memory allocation issue in wcn-\u0026gt;chan_survey\ndue to incorrect size calculation.\nThis commit uses kcalloc to allocate memory for wcn-\u0026gt;chan_survey,\nensuring proper initialization and preventing the use of uninitialized\nvalues when there are no frames on the channel.(CVE-2024-57997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: add index check to assert to avoid buffer overflow in _read_freq()\n\nPass the freq index to the assert function to make sure\nwe do not read a freq out of the opp-\u0026gt;rates[] table when called\nfrom the indexed variants:\ndev_pm_opp_find_freq_exact_indexed() or\ndev_pm_opp_find_freq_ceil/floor_indexed().\n\nAdd a secondary parameter to the assert function, unused\nfor assert_single_clk() then add assert_clk_index() which\nwill check for the clock index when called from the _indexed()\nfind functions.(CVE-2024-57998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()\n\nIn commit 4284c88fff0e (\u0026quot;PCI: designware-ep: Allow pci_epc_set_bar() update\ninbound map address\u0026quot;) set_bar() was modified to support dynamically\nchanging the backing physical address of a BAR that was already configured.\n\nThis means that set_bar() can be called twice, without ever calling\nclear_bar() (as calling clear_bar() would clear the BAR\u0026apos;s PCI address\nassigned by the host).\n\nThis can only be done if the new BAR size/flags does not differ from the\nexisting BAR configuration. Add these missing checks.\n\nIf we allow set_bar() to set e.g. a new BAR size that differs from the\nexisting BAR size, the new address translation range will be smaller than\nthe BAR size already determined by the host, which would mean that a read\npast the new BAR size would pass the iATU untranslated, which could allow\nthe host to read memory not belonging to the new struct pci_epf_bar.\n\nWhile at it, add comments which clarifies the support for dynamically\nchanging the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmi: ipmb: Add check devm_kasprintf() returned value\n\ndevm_kasprintf() can return a NULL pointer on failure but this\nreturned value is not checked.(CVE-2024-58051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table\n\nThe function atomctrl_get_smc_sclk_range_table() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to\nretrieve SMU_Info table, it returns NULL which is later dereferenced.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\nIn practice this should never happen as this code only gets called\non polaris chips and the vbios data table will always be present on\nthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix handling of received connection abort\n\nFix the handling of a connection abort that we\u0026apos;ve received. Though the\nabort is at the connection level, it needs propagating to the calls on that\nconnection. Whilst the propagation bit is performed, the calls aren\u0026apos;t then\nwoken up to go and process their termination, and as no further input is\nforthcoming, they just hang.\n\nAlso add some tracing for the logging of connection aborts.(CVE-2024-58053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: media: max96712: fix kernel oops when removing module\n\nThe following kernel oops is thrown when trying to remove the max96712\nmodule:\n\nUnable to handle kernel paging request at virtual address 00007375746174db\nMem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000\n[00007375746174db] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan\n snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2\n imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev\n snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils\n max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse\n [last unloaded: imx8_isi]\nCPU: 0 UID: 0 PID: 754 Comm: rmmod\n\t Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17\nTainted: [C]=CRAP\nHardware name: NXP i.MX95 19X19 board (DT)\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : led_put+0x1c/0x40\nlr : v4l2_subdev_put_privacy_led+0x48/0x58\nsp : ffff80008699bbb0\nx29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000\nx26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\nx23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8\nx20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000\nx11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010\nx8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d\nx5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1\nx2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473\nCall trace:\n led_put+0x1c/0x40\n v4l2_subdev_put_privacy_led+0x48/0x58\n v4l2_async_unregister_subdev+0x2c/0x1a4\n max96712_remove+0x1c/0x38 [max96712]\n i2c_device_remove+0x2c/0x9c\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1cc/0x228\n driver_detach+0x4c/0x98\n bus_remove_driver+0x6c/0xbc\n driver_unregister+0x30/0x60\n i2c_del_driver+0x54/0x64\n max96712_i2c_driver_exit+0x18/0x1d0 [max96712]\n __arm64_sys_delete_module+0x1a4/0x290\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xd8\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x190/0x194\nCode: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)\n---[ end trace 0000000000000000 ]---\n\nThis happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()\nis called again and the data is overwritten to point to sd, instead of\npriv. So, in remove(), the wrong pointer is passed to\nv4l2_async_unregister_subdev(), leading to a crash.(CVE-2024-58054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Fix ida_free call while not allocated\n\nIn the rproc_alloc() function, on error, put_device(\u0026amp;rproc-\u0026gt;dev) is\ncalled, leading to the call of the rproc_type_release() function.\nAn error can occurs before ida_alloc is called.\n\nIn such case in rproc_type_release(), the condition (rproc-\u0026gt;index \u0026gt;= 0) is\ntrue as rproc-\u0026gt;index has been initialized to 0.\nida_free() is called reporting a warning:\n[ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164\n[ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0\n[ 4.188854] ida_free called for id=0 which is not allocated.\n[ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000\n[ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+)\n[ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442\n[ 4.231481] Hardware name: STM32 (Device Tree Support)\n[ 4.236627] Workqueue: events_unbound deferred_probe_work_func\n[ 4.242504] Call trace:\n[ 4.242522] unwind_backtrace from show_stack+0x10/0x14\n[ 4.250218] show_stack from dump_stack_lvl+0x50/0x64\n[ 4.255274] dump_stack_lvl from __warn+0x80/0x12c\n[ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188\n[ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164\n[ 4.270565] ida_free from rproc_type_release+0x38/0x60\n[ 4.275832] rproc_type_release from device_release+0x30/0xa0\n[ 4.281601] device_release from kobject_put+0xc4/0x294\n[ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c\n[ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4\n[ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc]\n[ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc\n\nCalling ida_alloc earlier in rproc_alloc ensures that the rproc-\u0026gt;index is\nproperly set.(CVE-2024-58056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubifs: skip dumping tnc tree when zroot is null\n\nClearing slab cache will free all znode in memory and make\nc-\u0026gt;zroot.znode = NULL, then dumping tnc tree will access\nc-\u0026gt;zroot.znode which cause null pointer dereference.(CVE-2024-58058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: prohibit deactivating all links\n\nIn the internal API this calls this is a WARN_ON, but that\nshould remain since internally we want to know about bugs\nthat may cause this. Prevent deactivating all links in the\ndebugfs write directly.(CVE-2024-58061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: fix memory leaks and invalid access at probe error path\n\nDeinitialize at reverse order when probe fails.\n\nWhen init_sw_vars fails, rtl_deinit_core should not be called, specially\nnow that it destroys the rtl_wq workqueue.\n\nAnd call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be\nleaked.\n\nRemove pci_set_drvdata call as it will already be cleaned up by the core\ndriver code and could lead to memory leaks too. cf. commit 8d450935ae7f\n(\u0026quot;wireless: rtlwifi: remove unnecessary pci_set_drvdata()\u0026quot;) and\ncommit 3d86b93064c7 (\u0026quot;rtlwifi: Fix PCI probe error path orphaned memory\u0026quot;).(CVE-2024-58063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized\n\nIf a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth\nfrom the OPP table but the bandwidth table was not created because the\ninterconnect properties were missing in the OPP consumer node, the\nkernel will crash with:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000004\n...\npc : _read_bw+0x8/0x10\nlr : _opp_table_find_key+0x9c/0x174\n...\nCall trace:\n _read_bw+0x8/0x10 (P)\n _opp_table_find_key+0x9c/0x174 (L)\n _find_key+0x98/0x168\n dev_pm_opp_find_bw_ceil+0x50/0x88\n...\n\nIn order to fix the crash, create an assert function to check\nif the bandwidth table was created before trying to get a\nbandwidth with _read_bw().(CVE-2024-58068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: prevent adding a device which is already a team device lower\n\nPrevent adding a device which is already a team device lower,\ne.g. adding veth0 if vlan1 was already added and veth0 is a lower of\nvlan1.\n\nThis is not useful in practice and can lead to recursive locking:\n\n$ ip link add veth0 type veth peer name veth1\n$ ip link set veth0 up\n$ ip link set veth1 up\n$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1\n$ ip link add team0 type team\n$ ip link set veth0.1 down\n$ ip link set veth0.1 master team0\nteam0: Port device veth0.1 added\n$ ip link set veth0 down\n$ ip link set veth0 master team0\n\n============================================\nWARNING: possible recursive locking detected\n6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted\n--------------------------------------------\nip/7684 is trying to acquire lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n\nbut task is already holding lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\n\nCPU0\n----\nlock(team-\u0026gt;team_lock_key);\nlock(team-\u0026gt;team_lock_key);\n\n*** DEADLOCK ***\n\nMay be due to missing lock nesting notation\n\n2 locks held by ip/7684:\n\nstack backtrace:\nCPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:122)\nprint_deadlock_bug.cold (kernel/locking/lockdep.c:3040)\n__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)\n? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)\nlock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? lock_acquire (kernel/locking/lockdep.c:5822)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? fib_sync_up (net/ipv4/fib_semantics.c:2167)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nteam_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\n__dev_notify_flags (net/core/dev.c:8993)\n? __dev_change_flags (net/core/dev.c:8975)\ndev_change_flags (net/core/dev.c:9027)\nvlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)\n? br_device_event (net/bridge/br.c:143)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\ndev_open (net/core/dev.c:1519 net/core/dev.c:1505)\nteam_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)\n? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)\ndo_set_master (net/core/rtnetlink.c:2917)\ndo_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: remove unused check_buddy_priv\n\nCommit 2461c7d60f9f (\u0026quot;rtlwifi: Update header file\u0026quot;) introduced a global\nlist of private data structures.\n\nLater on, commit 26634c4b1868 (\u0026quot;rtlwifi Modify existing bits to match\nvendor version 2013.02.07\u0026quot;) started adding the private data to that list at\nprobe time and added a hook, check_buddy_priv to find the private data from\na similar device.\n\nHowever, that function was never used.\n\nBesides, though there is a lock for that list, it is never used. And when\nthe probe fails, the private data is never removed from the list. This\nwould cause a second probe to access freed memory.\n\nRemove the unused hook, structures and members, which will prevent the\npotential race condition on the list and its corruption during a second\nprobe when probe fails.(CVE-2024-58072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: handle fastopen disconnect correctly\n\nSyzbot was able to trigger a data stream corruption:\n\n WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n Modules linked in:\n CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\n RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 \u0026lt;0f\u0026gt; 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07\n RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293\n RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928\n R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000\n R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000\n FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074\n mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493\n release_sock+0x1aa/0x1f0 net/core/sock.c:3640\n inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]\n __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703\n mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755\n mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x1a6/0x270 net/socket.c:726\n ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583\n ___sys_sendmsg net/socket.c:2637 [inline]\n __sys_sendmsg+0x269/0x350 net/socket.c:2669\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 RIP: 0033:0x7f6e86ebfe69\n Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48\n RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69\n RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003\n RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc\n R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508\n \u0026lt;/TASK\u0026gt;\n\nThe root cause is the bad handling of disconnect() generated internally\nby the MPTCP protocol in case of connect FASTOPEN errors.\n\nAddress the issue increasing the socket disconnect counter even on such\na case, to allow other threads waiting on the same socket lock to\nproperly error out.(CVE-2025-21705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: consolidate suboption status\n\nMPTCP maintains the received sub-options status is the bitmask carrying\nthe received suboptions and in several bitfields carrying per suboption\nadditional info.\n\nZeroing the bitmask before parsing is not enough to ensure a consistent\nstatus, and the MPTCP code has to additionally clear some bitfiled\ndepending on the actually parsed suboption.\n\nThe above schema is fragile, and syzbot managed to trigger a path where\na relevant bitfield is not cleared/initialized:\n\n BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]\n BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n ack_update_msk net/mptcp/options.c:1060 [inline]\n mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233\n tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264\n tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916\n tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351\n ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:460 [inline]\n ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567\n __netif_receive_skb_one_core net/core/dev.c:5704 [inline]\n __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817\n process_backlog+0x4ad/0xa50 net/core/dev.c:6149\n __napi_poll+0xe7/0x980 net/core/dev.c:6902\n napi_poll net/core/dev.c:6971 [inline]\n net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093\n handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561\n __do_softirq+0x14/0x1a kernel/softirq.c:595\n do_softirq+0x9a/0x100 kernel/softirq.c:462\n __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]\n __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n neigh_hh_output include/net/neighbour.h:523 [inline]\n neigh_output include/net/neighbour.h:537 [inline]\n ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236\n __ip_finish_output+0x287/0x810\n ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434\n dst_output include/net/dst.h:450 [inline]\n ip_local_out net/ipv4/ip_output.c:130 [inline]\n __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536\n ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550\n __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468\n tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]\n tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829\n __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012\n tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618\n __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130\n __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496\n mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550\n mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889\n mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]\n mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]\n mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]\n mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750\n genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n \n---truncated---(CVE-2025-21707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: enable basic endpoint checking\n\nSyzkaller reports [1] encountering a common issue of utilizing a wrong\nusb endpoint type during URB submitting stage. This, in turn, triggers\na warning shown below.\n\nFor now, enable simple endpoint checking (specifically, bulk and\ninterrupt eps, testing control one is not essential) to mitigate\nthe issue with a view to do other related cosmetic changes later,\nif they are necessary.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv\u0026gt;\nModules linked in:\nCPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617\u0026gt;\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nCode: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8\u0026gt;\nRSP: 0018:ffffc9000441f740 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9\nRDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001\nRBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c\nFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733\n __dev_open+0x2d4/0x4e0 net/core/dev.c:1474\n __dev_change_flags+0x561/0x720 net/core/dev.c:8838\n dev_change_flags+0x8f/0x160 net/core/dev.c:8910\n devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177\n inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003\n sock_do_ioctl+0x116/0x280 net/socket.c:1222\n sock_ioctl+0x22e/0x6c0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fc04ef73d49\n...\n\nThis change has not been tested on real hardware.(CVE-2025-21708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \u0026quot;pasta\u0026quot; protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn\u0026apos;t influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side\u0026apos;s notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n// tcp_v4_rcv(-\u0026gt;)\n// tcp_rcv_established(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201\u0026lt;-\u0026gt;39222]: tcp_data_queue(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 259909392-\u0026gt;260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n [OFO queue: gap: 65480, len: 0]\n[5201\u0026lt;-\u0026gt;39222]: tcp_data_queue(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_transmit_skb(-\u0026gt;)\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]: tcp_select_window(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: (inet_csk(sk)-\u0026gt;icsk_ack.pending \u0026amp; ICSK_ACK_NOMEM) ? --\u0026gt; TRUE\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n returning 0\n[5201\u0026lt;-\u0026gt;39222]: tcp_select_window(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201\u0026lt;-\u0026gt;39222]: [__tcp_transmit_skb(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: tcp_rcv_established(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: tcp_v4_rcv(\u0026lt;-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don\u0026apos;t update tp-\u0026gt;rcv_wnd and tp-\u0026gt;rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201\u0026lt;-\u0026gt;39222]: [new_win \u0026gt;= (2 * win_now) ? --\u0026gt; time_to_ack = 0]\n[5201\u0026lt;-\u0026gt;39222]: NOT calling tcp_send_ack()\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(\u0026lt;-)\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 260040464-\u0026gt;260040464 (0), unread 5559696, qlen 85, ofoq 0]\n returning 6104 bytes\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(\u0026lt;-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp-\u0026gt;rcv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---(CVE-2025-21710)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/rose: prevent integer overflows in rose_setsockopt()\n\nIn case of possible unpredictably large arguments passed to\nrose_setsockopt() and multiplied by extra values on top of that,\ninteger overflows may occur.\n\nDo the safest minimum and fix these issues by checking the\ncontents of \u0026apos;opt\u0026apos; and returning -EINVAL if they are too large. Also,\nswitch to unsigned int and remove useless check for negative \u0026apos;opt\u0026apos;\nin ROSE_IDLE case.(CVE-2025-21711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix uninit-value in vxlan_vnifilter_dump()\n\nKMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].\n\nIf the length of the netlink message payload is less than\nsizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes\nbeyond the message. This can lead to uninit-value access. Fix this by\nreturning an error in such situations.\n\n[1]\nBUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786\n netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317\n __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432\n netlink_dump_start include/linux/netlink.h:340 [inline]\n rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline]\n rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882\n netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542\n rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944\n netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347\n netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4110 [inline]\n slab_alloc_node mm/slub.c:4153 [inline]\n kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205\n kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587\n __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196\n netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete intermediate secpath entry in packet offload mode\n\nPackets handled by hardware have added secpath as a way to inform XFRM\ncore code that this path was already handled. That secpath is not needed\nat all after policy is checked and it is removed later in the stack.\n\nHowever, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward),\nthat secpath is not removed and packets which already were handled are reentered\nto the driver TX path with xfrm_offload set.\n\nThe following kernel panic is observed in mlx5 in such case:\n\n mlx5_core 0000:04:00.0 enp4s0f0np0: Link up\n mlx5_core 0000:04:00.1 enp4s0f1np1: Link up\n Initializing XFRM netlink socket\n IPsec XFRM device driver\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor instruction fetch in kernel mode\n #PF: error_code(0x0010) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0010 [#1] PREEMPT SMP\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n RIP: 0010:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 0018:ffffb87380003800 EFLAGS: 00010206\n RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf\n RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00\n RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010\n R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00\n R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e\n FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? show_regs+0x63/0x70\n ? __die_body+0x20/0x60\n ? __die+0x2b/0x40\n ? page_fault_oops+0x15c/0x550\n ? do_user_addr_fault+0x3ed/0x870\n ? exc_page_fault+0x7f/0x190\n ? asm_exc_page_fault+0x27/0x30\n mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core]\n mlx5e_xmit+0x58e/0x1980 [mlx5_core]\n ? __fib_lookup+0x6a/0xb0\n dev_hard_start_xmit+0x82/0x1d0\n sch_direct_xmit+0xfe/0x390\n __dev_queue_xmit+0x6d8/0xee0\n ? __fib_lookup+0x6a/0xb0\n ? internal_add_timer+0x48/0x70\n ? mod_timer+0xe2/0x2b0\n neigh_resolve_output+0x115/0x1b0\n __neigh_update+0x26a/0xc50\n neigh_update+0x14/0x20\n arp_process+0x2cb/0x8e0\n ? __napi_build_skb+0x5e/0x70\n arp_rcv+0x11e/0x1c0\n ? dev_gro_receive+0x574/0x820\n __netif_receive_skb_list_core+0x1cf/0x1f0\n netif_receive_skb_list_internal+0x183/0x2a0\n napi_complete_done+0x76/0x1c0\n mlx5e_napi_poll+0x234/0x7a0 [mlx5_core]\n __napi_poll+0x2d/0x1f0\n net_rx_action+0x1a6/0x370\n ? atomic_notifier_call_chain+0x3b/0x50\n ? irq_int_handler+0x15/0x20 [mlx5_core]\n handle_softirqs+0xb9/0x2f0\n ? handle_irq_event+0x44/0x60\n irq_exit_rcu+0xdb/0x100\n common_interrupt+0x98/0xc0\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_common_interrupt+0x27/0x40\n RIP: 0010:pv_native_safe_halt+0xb/0x10\n Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22\n 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb\n40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8\n RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680\n RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4\n RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70\n R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40\n R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8\n ? default_idle+0x9/0x20\n arch_cpu_idle+0x9/0x10\n default_idle_call+0x29/0xf0\n do_idle+0x1f2/0x240\n cpu_startup_entry+0x2c/0x30\n rest_init+0xe7/0x100\n start_kernel+0x76b/0xb90\n x86_64_start_reservations+0x18/0x30\n x86_64_start_kernel+0xc0/0x110\n ? setup_ghcb+0xe/0x130\n common_startup_64+0x13e/0x141\n \u0026lt;/TASK\u0026gt;\n Modules linked in: esp4_offload esp4 xfrm_interface\nxfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf\n---truncated---(CVE-2025-21720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()\n\nResolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()\nwhere shifting the constant \u0026quot;1\u0026quot; (of type int) by bitmap-\u0026gt;mapped.pgshift\n(an unsigned long value) could result in undefined behavior.\n\nThe constant \u0026quot;1\u0026quot; defaults to a 32-bit \u0026quot;int\u0026quot;, and when \u0026quot;pgshift\u0026quot; exceeds\n31 (e.g., pgshift = 63) the shift operation overflows, as the result\ncannot be represented in a 32-bit type.\n\nTo resolve this, the constant is updated to \u0026quot;1UL\u0026quot;, promoting it to an\nunsigned long type to match the operand\u0026apos;s type.(CVE-2025-21724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix oops due to unset link speed\n\nIt isn\u0026apos;t guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always\nbe set by the server, so the client must handle any values and then\nprevent oopses like below from happening:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nRIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48\n89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8\ne7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 \u0026lt;48\u0026gt; f7 74 24 18 48 89\nc3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24\nRSP: 0018:ffffc90001817be0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99\nRDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228\nRBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac\nR10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200\nR13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58\nFS: 00007fe27119e740(0000) GS:ffff888148600000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0x159/0x1b0\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? do_error_trap+0x90/0x130\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? exc_divide_error+0x39/0x50\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? asm_exc_divide_error+0x1a/0x20\n ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? seq_read_iter+0x42e/0x790\n seq_read_iter+0x19a/0x790\n proc_reg_read_iter+0xbe/0x110\n ? __pfx_proc_reg_read_iter+0x10/0x10\n vfs_read+0x469/0x570\n ? do_user_addr_fault+0x398/0x760\n ? __pfx_vfs_read+0x10/0x10\n ? find_held_lock+0x8a/0xa0\n ? __pfx_lock_release+0x10/0x10\n ksys_read+0xd3/0x170\n ? __pfx_ksys_read+0x10/0x10\n ? __rcu_read_unlock+0x50/0x270\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe271288911\nCode: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8\n20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 \u0026lt;48\u0026gt; 3d\n00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911\nRDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003\nRBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\n\nFix this by setting cifs_server_iface::speed to a sane value (1Gbps)\nby default when link speed is unset.(CVE-2025-21725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n ...\n padata_reorder\n // processes all remaining\n // requests then breaks\n while (1) {\n if (!padata)\n break;\n ...\n }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t // new request added\n\t\t\t\t list_add\n // sees the new request\n queue_work(reorder_work)\n\t\t\t\t padata_reorder\n\t\t\t\t queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Send signals asynchronously if !preemptible\n\nBPF programs can execute in all kinds of contexts and when a program\nrunning in a non-preemptible context uses the bpf_send_signal() kfunc,\nit will cause issues because this kfunc can sleep.\nChange `irqs_disabled()` to `!preemptible()`.(CVE-2025-21728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: Fix class @block_class\u0026apos;s subsystem refcount leakage\n\nblkcg_fill_root_iostats() iterates over @block_class\u0026apos;s devices by\nclass_dev_iter_(init|next)(), but does not end iterating with\nclass_dev_iter_exit(), so causes the class\u0026apos;s subsystem refcount leakage.\n\nFix by ending the iterating with class_dev_iter_exit().(CVE-2025-21745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()\n\nWhen getting the IRQ we use k3_udma_glue_tx_get_irq() which returns\nnegative error value on error. So not NULL check is not sufficient\nto deteremine if IRQ is valid. Check that IRQ is greater then zero\nto ensure it is valid.\n\nThere is no issue at probe time but at runtime user can invoke\n.set_channels which results in the following call chain.\nam65_cpsw_set_channels()\n am65_cpsw_nuss_update_tx_rx_chns()\n am65_cpsw_nuss_remove_tx_chns()\n am65_cpsw_nuss_init_tx_chns()\n\nAt this point if am65_cpsw_nuss_init_tx_chns() fails due to\nk3_udma_glue_tx_get_irq() then tx_chn-\u0026gt;irq will be set to a\nnegative value.\n\nThen, at subsequent .set_channels with higher channel count we\nwill attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()\nleading to a kernel warning.\n\nThe issue is present in the original commit that introduced this driver,\nalthough there, am65_cpsw_nuss_update_tx_rx_chns() existed as\nam65_cpsw_nuss_update_tx_chns().(CVE-2025-21799)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix warnings during S3 suspend\n\nThe enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),\nand the later one may call the preempt_schedule_common() function,\nresulting in a thread switch and causing the CPU to be in an interrupt\nenabled state after the enable_gpe_wakeup() function returns, leading\nto the warnings as follow.\n\n[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8\n[ C0] ...\n[ C0] Call Trace:\n[ C0] [\u0026lt;90000000002243b4\u0026gt;] show_stack+0x64/0x188\n[ C0] [\u0026lt;900000000164673c\u0026gt;] dump_stack_lvl+0x60/0x88\n[ C0] [\u0026lt;90000000002687e4\u0026gt;] __warn+0x8c/0x148\n[ C0] [\u0026lt;90000000015e9978\u0026gt;] report_bug+0x1c0/0x2b0\n[ C0] [\u0026lt;90000000016478e4\u0026gt;] do_bp+0x204/0x3b8\n[ C0] [\u0026lt;90000000025b1924\u0026gt;] exception_handlers+0x1924/0x10000\n[ C0] [\u0026lt;9000000000343bbc\u0026gt;] ktime_get+0xbc/0xc8\n[ C0] [\u0026lt;9000000000354c08\u0026gt;] tick_sched_timer+0x30/0xb0\n[ C0] [\u0026lt;90000000003408e0\u0026gt;] __hrtimer_run_queues+0x160/0x378\n[ C0] [\u0026lt;9000000000341f14\u0026gt;] hrtimer_interrupt+0x144/0x388\n[ C0] [\u0026lt;9000000000228348\u0026gt;] constant_timer_interrupt+0x38/0x48\n[ C0] [\u0026lt;90000000002feba4\u0026gt;] __handle_irq_event_percpu+0x64/0x1e8\n[ C0] [\u0026lt;90000000002fed48\u0026gt;] handle_irq_event_percpu+0x20/0x80\n[ C0] [\u0026lt;9000000000306b9c\u0026gt;] handle_percpu_irq+0x5c/0x98\n[ C0] [\u0026lt;90000000002fd4a0\u0026gt;] generic_handle_domain_irq+0x30/0x48\n[ C0] [\u0026lt;9000000000d0c7b0\u0026gt;] handle_cpu_irq+0x70/0xa8\n[ C0] [\u0026lt;9000000001646b30\u0026gt;] handle_loongarch_irq+0x30/0x48\n[ C0] [\u0026lt;9000000001646bc8\u0026gt;] do_vint+0x80/0xe0\n[ C0] [\u0026lt;90000000002aea1c\u0026gt;] finish_task_switch.isra.0+0x8c/0x2a8\n[ C0] [\u0026lt;900000000164e34c\u0026gt;] __schedule+0x314/0xa48\n[ C0] [\u0026lt;900000000164ead8\u0026gt;] schedule+0x58/0xf0\n[ C0] [\u0026lt;9000000000294a2c\u0026gt;] worker_thread+0x224/0x498\n[ C0] [\u0026lt;900000000029d2f0\u0026gt;] kthread+0xf8/0x108\n[ C0] [\u0026lt;9000000000221f28\u0026gt;] ret_from_kernel_thread+0xc/0xa4\n[ C0]\n[ C0] ---[ end trace 0000000000000000 ]---\n\nThe root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect\nacpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause\na thread switch. Since there is no longer concurrent execution during\nloongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()\ndirectly in enable_gpe_wakeup().\n\nThe solution is similar to commit 22db06337f590d01 (\u0026quot;ACPI: sleep: Avoid\nbreaking S3 wakeup due to might_sleep()\u0026quot;).(CVE-2025-21803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n $ cat /proc/iomem\n 30000000-37ffffff :\n 38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n $ cat /proc/iomem\n 30000000-37ffffff : memory2\n 38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: let net.core.dev_weight always be non-zero\n\nThe following problem was encountered during stability test:\n\n(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\\n\treturned 1, exceeding its budget of 0.\n------------[ cut here ]------------\nlist_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\\n\tnext=ffff88905f746e40.\nWARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\\n\t__list_add_valid_or_report+0xf3/0x130\nCPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+\nRIP: 0010:__list_add_valid_or_report+0xf3/0x130\nCall Trace:\n? __warn+0xcd/0x250\n? __list_add_valid_or_report+0xf3/0x130\nenqueue_to_backlog+0x923/0x1070\nnetif_rx_internal+0x92/0x2b0\n__netif_rx+0x15/0x170\nloopback_xmit+0x2ef/0x450\ndev_hard_start_xmit+0x103/0x490\n__dev_queue_xmit+0xeac/0x1950\nip_finish_output2+0x6cc/0x1620\nip_output+0x161/0x270\nip_push_pending_frames+0x155/0x1a0\nraw_sendmsg+0xe13/0x1550\n__sys_sendto+0x3bf/0x4e0\n__x64_sys_sendto+0xdc/0x1b0\ndo_syscall_64+0x5b/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reproduction command is as follows:\n sysctl -w net.core.dev_weight=0\n ping 127.0.0.1\n\nThis is because when the napi\u0026apos;s weight is set to 0, process_backlog() may\nreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing this\nnapi to be re-polled in net_rx_action() until __do_softirq() times out.\nSince the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can\nbe retriggered in enqueue_to_backlog(), causing this issue.\n\nMaking the napi\u0026apos;s weight always non-zero solves this problem.\n\nTriggering this issue requires system-wide admin (setting is\nnot namespaced).(CVE-2025-21806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: xdp: Disallow attaching device-bound programs in generic mode\n\nDevice-bound programs are used to support RX metadata kfuncs. These\nkfuncs are driver-specific and rely on the driver context to read the\nmetadata. This means they can\u0026apos;t work in generic XDP mode. However, there\nis no check to disallow such programs from being attached in generic\nmode, in which case the metadata kfuncs will be called in an invalid\ncontext, leading to crashes.\n\nFix this by adding a check to disallow attaching device-bound programs\nin generic mode.(CVE-2025-21808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: class: Fix wild pointer dereferences in API class_dev_iter_next()\n\nThere are a potential wild pointer dereferences issue regarding APIs\nclass_dev_iter_(init|next|exit)(), as explained by below typical usage:\n\n// All members of @iter are wild pointers.\nstruct class_dev_iter iter;\n\n// class_dev_iter_init(@iter, @class, ...) checks parameter @class for\n// potential class_to_subsys() error, and it returns void type and does\n// not initialize its output parameter @iter, so caller can not detect\n// the error and continues to invoke class_dev_iter_next(@iter) even if\n// @iter still contains wild pointers.\nclass_dev_iter_init(\u0026amp;iter, ...);\n\n// Dereference these wild pointers in @iter here once suffer the error.\nwhile (dev = class_dev_iter_next(\u0026amp;iter)) { ... };\n\n// Also dereference these wild pointers here.\nclass_dev_iter_exit(\u0026amp;iter);\n\nActually, all callers of these APIs have such usage pattern in kernel tree.\nFix by:\n- Initialize output parameter @iter by memset() in class_dev_iter_init()\n and give callers prompt by pr_crit() for the error.\n- Check if @iter is valid in class_dev_iter_next().(CVE-2025-21810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: protect access to buffers with no active references\n\nnilfs_lookup_dirty_data_buffers(), which iterates through the buffers\nattached to dirty data folios/pages, accesses the attached buffers without\nlocking the folios/pages.\n\nFor data cache, nilfs_clear_folio_dirty() may be called asynchronously\nwhen the file system degenerates to read only, so\nnilfs_lookup_dirty_data_buffers() still has the potential to cause use\nafter free issues when buffers lose the protection of their dirty state\nmidway due to this asynchronous clearing and are unintentionally freed by\ntry_to_free_buffers().\n\nEliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nax25: rcu protect dev-\u0026gt;ax25_ptr\n\nsyzbot found a lockdep issue [1].\n\nWe should remove ax25 RTNL dependency in ax25_setsockopt()\n\nThis should also fix a variety of possible UAF in ax25.\n\n[1]\n\nWARNING: possible circular locking dependency detected\n6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted\n------------------------------------------------------\nsyz.5.1818/12806 is trying to acquire lock:\n ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n\nbut task is already holding lock:\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #1 (sk_lock-AF_AX25){+.+.}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n lock_sock_nested+0x48/0x100 net/core/sock.c:3642\n lock_sock include/net/sock.h:1618 [inline]\n ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]\n ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146\n notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85\n __dev_notify_flags+0x207/0x400\n dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026\n dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563\n dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820\n sock_do_ioctl+0x240/0x460 net/socket.c:1234\n sock_ioctl+0x626/0x8e0 net/socket.c:1339\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892\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\n-\u0026gt; #0 (rtnl_mutex){+.+.}-{4:4}:\n check_prev_add kernel/locking/lockdep.c:3161 [inline]\n check_prevs_add kernel/locking/lockdep.c:3280 [inline]\n validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904\n __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735\n ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2324\n __sys_setsockopt net/socket.c:2349 [inline]\n __do_sys_setsockopt net/socket.c:2355 [inline]\n __se_sys_setsockopt net/socket.c:2352 [inline]\n __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352\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\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(sk_lock-AF_AX25);\n lock(rtnl_mutex);\n lock(sk_lock-AF_AX25);\n lock(rtnl_mutex);\n\n *** DEADLOCK ***\n\n1 lock held by syz.5.1818/12806:\n #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/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_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074\n check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206\n check_prev_add kernel/locking/lockdep.c:3161 [inline]\n check_prevs_add kernel/lockin\n---truncated---(CVE-2025-21812)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don\u0026apos;t flush non-uploaded STAs\n\nIf STA state is pre-moved to AUTHORIZED (such as in IBSS\nscenarios) and insertion fails, the station is freed.\nIn this case, the driver never knew about the station,\nso trying to flush it is unexpected and may crash.\n\nCheck if the sta was uploaded to the driver before and\nfix this.(CVE-2025-21828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: avoid holding freeze_mutex during mmap operation\n\nWe use map-\u0026gt;freeze_mutex to prevent races between map_freeze() and\nmemory mapping BPF map contents with writable permissions. The way we\nnaively do this means we\u0026apos;ll hold freeze_mutex for entire duration of all\nthe mm and VMA manipulations, which is completely unnecessary. This can\npotentially also lead to deadlocks, as reported by syzbot in [0].\n\nSo, instead, hold freeze_mutex only during writeability checks, bump\n(proactively) \u0026quot;write active\u0026quot; count for the map, unlock the mutex and\nproceed with mmap logic. And only if something went wrong during mmap\nlogic, then undo that \u0026quot;write active\u0026quot; counter increment.\n\n [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)",
"id": "OESA-2025-1339",
"modified": "2026-08-06T11:08:26Z",
"published": "2025-03-29T11:08:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47143"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47809"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56603"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56606"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56637"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56648"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56783"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57876"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57986"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21716"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21799"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21812"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21853"
}
],
"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-2024-47143",
"CVE-2024-47809",
"CVE-2024-48881",
"CVE-2024-53214",
"CVE-2024-56603",
"CVE-2024-56606",
"CVE-2024-56637",
"CVE-2024-56642",
"CVE-2024-56648",
"CVE-2024-56670",
"CVE-2024-56704",
"CVE-2024-56783",
"CVE-2024-56785",
"CVE-2024-57838",
"CVE-2024-57876",
"CVE-2024-57973",
"CVE-2024-57978",
"CVE-2024-57986",
"CVE-2024-57993",
"CVE-2024-57997",
"CVE-2024-57998",
"CVE-2024-58006",
"CVE-2024-58034",
"CVE-2024-58051",
"CVE-2024-58052",
"CVE-2024-58053",
"CVE-2024-58054",
"CVE-2024-58056",
"CVE-2024-58058",
"CVE-2024-58061",
"CVE-2024-58063",
"CVE-2024-58068",
"CVE-2024-58071",
"CVE-2024-58072",
"CVE-2025-21687",
"CVE-2025-21705",
"CVE-2025-21707",
"CVE-2025-21708",
"CVE-2025-21710",
"CVE-2025-21711",
"CVE-2025-21715",
"CVE-2025-21716",
"CVE-2025-21720",
"CVE-2025-21724",
"CVE-2025-21725",
"CVE-2025-21726",
"CVE-2025-21727",
"CVE-2025-21728",
"CVE-2025-21745",
"CVE-2025-21799",
"CVE-2025-21803",
"CVE-2025-21804",
"CVE-2025-21806",
"CVE-2025-21808",
"CVE-2025-21810",
"CVE-2025-21811",
"CVE-2025-21812",
"CVE-2025-21828",
"CVE-2025-21853"
]
}
oesa-2025-1340
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in cleanup_bearer().
[0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830
[1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid potential out-of-bound access in fill_frame_info()
syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one.
Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case.
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL.
E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash
This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash.
If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect.
So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb.
Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68(CVE-2024-56670)
In the Linux kernel, the following vulnerability has been resolved:
rdma/cxgb4: Prevent potential integer overflow on 32bit
The "gl->tot_len" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an integer wrapping bug. Use size_add() to prevent this.(CVE-2024-57973)
In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Fix potential error pointer dereference in detach_pm()
The proble is on the first line:
if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i]))
If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that.(CVE-2024-57978)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections
A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop in hid_apply_multiplier."), but the other has not been fixed.
This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying:
* "The Resolution Multiplier control must be contained in the same
* Logical Collection as the control(s) to which it is to be applied.
...
* If no Logical Collection is
* defined, the Resolution Multiplier is associated with all
* controls in the report."
* HID Usage Table, v1.12, Section 4.3.1, p30
*
* Thus, search from the current collection upwards until we find a
* logical collection...
The comment and the code overlook the possibility that none of the collections found may be a Logical Collection.
The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection.(CVE-2024-57986)
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check
syzbot has found a type mismatch between a USB pipe and the transfer endpoint, which is triggered by the hid-thrustmaster driver[1]. There is a number of similar, already fixed issues [2]. In this case as in others, implementing check for endpoint type fixes the issue.
[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470 [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: fix channel survey memory allocation size
KASAN reported a memory allocation issue in wcn->chan_survey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chan_survey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel.(CVE-2024-57997)
In the Linux kernel, the following vulnerability has been resolved:
OPP: add index check to assert to avoid buffer overflow in _read_freq()
Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: dev_pm_opp_find_freq_exact_indexed() or dev_pm_opp_find_freq_ceil/floor_indexed().
Add a secondary parameter to the assert function, unused for assert_single_clk() then add assert_clk_index() which will check for the clock index when called from the _indexed() find functions.(CVE-2024-57998)
In the Linux kernel, the following vulnerability has been resolved:
PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()
In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.
This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host).
This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.
If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar.
While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
ipmi: ipmb: Add check devm_kasprintf() returned value
devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.(CVE-2024-58051)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table
The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix handling of received connection abort
Fix the handling of a connection abort that we've received. Though the abort is at the connection level, it needs propagating to the calls on that connection. Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang.
Also add some tracing for the logging of connection aborts.(CVE-2024-58053)
In the Linux kernel, the following vulnerability has been resolved:
staging: media: max96712: fix kernel oops when removing module
The following kernel oops is thrown when trying to remove the max96712 module:
Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2 imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse [last unloaded: imx8_isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr : v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: led_put+0x1c/0x40 v4l2_subdev_put_privacy_led+0x48/0x58 v4l2_async_unregister_subdev+0x2c/0x1a4 max96712_remove+0x1c/0x38 [max96712] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x4c/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 max96712_i2c_driver_exit+0x18/0x1d0 [max96712] __arm64_sys_delete_module+0x1a4/0x290 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]---
This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2_async_unregister_subdev(), leading to a crash.(CVE-2024-58054)
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Fix ida_free call while not allocated
In the rproc_alloc() function, on error, put_device(&rproc->dev) is called, leading to the call of the rproc_type_release() function. An error can occurs before ida_alloc is called.
In such case in rproc_type_release(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. ida_free() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] ida_free called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: events_unbound deferred_probe_work_func [ 4.242504] Call trace: [ 4.242522] unwind_backtrace from show_stack+0x10/0x14 [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64 [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188 [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164 [ 4.270565] ida_free from rproc_type_release+0x38/0x60 [ 4.275832] rproc_type_release from device_release+0x30/0xa0 [ 4.281601] device_release from kobject_put+0xc4/0x294 [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4 [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc] [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc
Calling ida_alloc earlier in rproc_alloc ensures that the rproc->index is properly set.(CVE-2024-58056)
In the Linux kernel, the following vulnerability has been resolved:
ubifs: skip dumping tnc tree when zroot is null
Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.(CVE-2024-58058)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: prohibit deactivating all links
In the internal API this calls this is a WARN_ON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly.(CVE-2024-58061)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: fix memory leaks and invalid access at probe error path
Deinitialize at reverse order when probe fails.
When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue.
And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked.
Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").(CVE-2024-58063)
In the Linux kernel, the following vulnerability has been resolved:
OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized
If a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : _read_bw+0x8/0x10 lr : _opp_table_find_key+0x9c/0x174 ... Call trace: _read_bw+0x8/0x10 (P) _opp_table_find_key+0x9c/0x174 (L) _find_key+0x98/0x168 dev_pm_opp_find_bw_ceil+0x50/0x88 ...
In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with _read_bw().(CVE-2024-58068)
In the Linux kernel, the following vulnerability has been resolved:
team: prevent adding a device which is already a team device lower
Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.
This is not useful in practice and can lead to recursive locking:
$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0
============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
lock(team->team_lock_key); lock(team->team_lock_key);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by ip/7684:
stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: remove unused check_buddy_priv
Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures.
Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device.
However, that function was never used.
Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory.
Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails.(CVE-2024-58072)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: handle fastopen disconnect correctly
Syzbot was able to trigger a data stream corruption:
WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493 release_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703 mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:726 _syssendmsg+0x52a/0x7e0 net/socket.c:2583 _sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 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 RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 </TASK>
The root cause is the bad handling of disconnect() generated internally by the MPTCP protocol in case of connect FASTOPEN errors.
Address the issue increasing the socket disconnect counter even on such a case, to allow other threads waiting on the same socket lock to properly error out.(CVE-2025-21705)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: consolidate suboption status
MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info.
Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption.
The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized:
BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
---truncated---(CVE-2025-21707)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: rtl8150: enable basic endpoint checking
Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.
For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...
This change has not been tested on real hardware.(CVE-2025-21708)
In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations.
However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution.
The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.
The following excerpt of a logging session, with own comments added, shows more in detail what is happening:
// tcp_v4_rcv(->) // tcp_rcv_established(->) 5201<->39222: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
5201<->39222: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0]
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
5201<->39222: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0
5201<->39222: ADVERTISING WIN 0, ACK_SEQ: 265600160
// Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: new_win = 0, win_now = 131184, 2 * win_now = 262368: new_win >= (2 * win_now) ? --> time_to_ack = 0: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
[copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
returning 6104 bytes
// After each read, the algorithm for calculating the new receive // window in __tcp_cleanup_rbuf() finds it is too small to advertise // or to update tp->rcv_wnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side.
5201<->39222: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 5201<->39222: [new_win = 262144, win_now = 131184, 2 * win_n ---truncated---(CVE-2025-21710)
In the Linux kernel, the following vulnerability has been resolved:
net/rose: prevent integer overflows in rose_setsockopt()
In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur.
Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case.(CVE-2025-21711)
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.
This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool.(CVE-2025-21715)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix uninit-value in vxlan_vnifilter_dump()
KMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].
If the length of the netlink message payload is less than sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes beyond the message. This can lead to uninit-value access. Fix this by returning an error in such situations.
[1] BUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786 netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317 __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432 netlink_dump_start include/linux/netlink.h:340 [inline] rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline] rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882 netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542 rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 _syssendmsg+0x7f4/0xb50 net/socket.c:2583 _sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4110 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205 kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196 netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 _syssendmsg+0x7f4/0xb50 net/socket.c:2583 _sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete intermediate secpath entry in packet offload mode
Packets handled by hardware have added secpath as a way to inform XFRM core code that this path was already handled. That secpath is not needed at all after policy is checked and it is removed later in the stack.
However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward), that secpath is not removed and packets which already were handled are reentered to the driver TX path with xfrm_offload set.
The following kernel panic is observed in mlx5 in such case:
mlx5_core 0000:04:00.0 enp4s0f0np0: Link up mlx5_core 0000:04:00.1 enp4s0f1np1: Link up Initializing XFRM netlink socket IPsec XFRM device driver BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: Oops: 0010 [#1] PREEMPT SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffb87380003800 EFLAGS: 00010206 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? show_regs+0x63/0x70 ? __die_body+0x20/0x60 ? __die+0x2b/0x40 ? page_fault_oops+0x15c/0x550 ? do_user_addr_fault+0x3ed/0x870 ? exc_page_fault+0x7f/0x190 ? asm_exc_page_fault+0x27/0x30 mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core] mlx5e_xmit+0x58e/0x1980 [mlx5_core] ? __fib_lookup+0x6a/0xb0 dev_hard_start_xmit+0x82/0x1d0 sch_direct_xmit+0xfe/0x390 __dev_queue_xmit+0x6d8/0xee0 ? __fib_lookup+0x6a/0xb0 ? internal_add_timer+0x48/0x70 ? mod_timer+0xe2/0x2b0 neigh_resolve_output+0x115/0x1b0 __neigh_update+0x26a/0xc50 neigh_update+0x14/0x20 arp_process+0x2cb/0x8e0 ? __napi_build_skb+0x5e/0x70 arp_rcv+0x11e/0x1c0 ? dev_gro_receive+0x574/0x820 __netif_receive_skb_list_core+0x1cf/0x1f0 netif_receive_skb_list_internal+0x183/0x2a0 napi_complete_done+0x76/0x1c0 mlx5e_napi_poll+0x234/0x7a0 [mlx5_core] __napi_poll+0x2d/0x1f0 net_rx_action+0x1a6/0x370 ? atomic_notifier_call_chain+0x3b/0x50 ? irq_int_handler+0x15/0x20 [mlx5_core] handle_softirqs+0xb9/0x2f0 ? handle_irq_event+0x44/0x60 irq_exit_rcu+0xdb/0x100 common_interrupt+0x98/0xc0 </IRQ> <TASK> asm_common_interrupt+0x27/0x40 RIP: 0010:pv_native_safe_halt+0xb/0x10 Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb 40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8 RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680 RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4 RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70 R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8 ? default_idle+0x9/0x20 arch_cpu_idle+0x9/0x10 default_idle_call+0x29/0xf0 do_idle+0x1f2/0x240 cpu_startup_entry+0x2c/0x30 rest_init+0xe7/0x100 start_kernel+0x76b/0xb90 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xc0/0x110 ? setup_ghcb+0xe/0x130 common_startup_64+0x13e/0x141 </TASK> Modules linked in: esp4_offload esp4 xfrm_interface xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf ---truncated---(CVE-2025-21720)
In the Linux kernel, the following vulnerability has been resolved:
iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()
Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index() where shifting the constant "1" (of type int) by bitmap->mapped.pgshift (an unsigned long value) could result in undefined behavior.
The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds 31 (e.g., pgshift = 63) the shift operation overflows, as the result cannot be represented in a 32-bit type.
To resolve this, the constant is updated to "1UL", promoting it to an unsigned long type to match the operand's type.(CVE-2025-21724)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix oops due to unset link speed
It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always be set by the server, so the client must handle any values and then prevent oopses like below from happening:
Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8 e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89 c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24 RSP: 0018:ffffc90001817be0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99 RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228 RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200 R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58 FS: 00007fe27119e740(0000) GS:ffff888148600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0x159/0x1b0 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? do_error_trap+0x90/0x130 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? exc_divide_error+0x39/0x50 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? asm_exc_divide_error+0x1a/0x20 ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs] ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? seq_read_iter+0x42e/0x790 seq_read_iter+0x19a/0x790 proc_reg_read_iter+0xbe/0x110 ? __pfx_proc_reg_read_iter+0x10/0x10 vfs_read+0x469/0x570 ? do_user_addr_fault+0x398/0x760 ? __pfx_vfs_read+0x10/0x10 ? find_held_lock+0x8a/0xa0 ? __pfx_lock_release+0x10/0x10 ksys_read+0xd3/0x170 ? __pfx_ksys_read+0x10/0x10 ? __rcu_read_unlock+0x50/0x270 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe271288911 Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911 RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003 RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000 </TASK>
Fix this by setting cifs_server_iface::speed to a sane value (1Gbps) by default when link speed is unset.(CVE-2025-21725)
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:
crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context> invoke_padata_reorder // UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.(CVE-2025-21726)
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Send signals asynchronously if !preemptible
BPF programs can execute in all kinds of contexts and when a program
running in a non-preemptible context uses the bpf_send_signal() kfunc,
it will cause issues because this kfunc can sleep.
Change irqs_disabled() to !preemptible().(CVE-2025-21728)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix class @block_class's subsystem refcount leakage
blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage.
Fix by ending the iterating with class_dev_iter_exit().(CVE-2025-21745)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()
When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid.
There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns()
At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value.
Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning.
The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns().(CVE-2025-21799)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix warnings during S3 suspend
The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(), and the later one may call the preempt_schedule_common() function, resulting in a thread switch and causing the CPU to be in an interrupt enabled state after the enable_gpe_wakeup() function returns, leading to the warnings as follow.
[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]---
The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Since there is no longer concurrent execution during loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes() directly in enable_gpe_wakeup().
The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep()").(CVE-2025-21803)
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.
Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:
$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:
$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3
In the Linux kernel, the following vulnerability has been resolved:
net: let net.core.dev_weight always be non-zero
The following problem was encountered during stability test:
(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1
This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue.
Making the napi's weight always non-zero solves this problem.
Triggering this issue requires system-wide admin (setting is not namespaced).(CVE-2025-21806)
In the Linux kernel, the following vulnerability has been resolved:
net: xdp: Disallow attaching device-bound programs in generic mode
Device-bound programs are used to support RX metadata kfuncs. These kfuncs are driver-specific and rely on the driver context to read the metadata. This means they can't work in generic XDP mode. However, there is no check to disallow such programs from being attached in generic mode, in which case the metadata kfuncs will be called in an invalid context, leading to crashes.
Fix this by adding a check to disallow attaching device-bound programs in generic mode.(CVE-2025-21808)
In the Linux kernel, the following vulnerability has been resolved:
driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()
There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage:
// All members of @iter are wild pointers. struct class_dev_iter iter;
// class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...);
// Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... };
// Also dereference these wild pointers here. class_dev_iter_exit(&iter);
Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next().(CVE-2025-21810)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: protect access to buffers with no active references
nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages.
For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers().
Eliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)
In the Linux kernel, the following vulnerability has been resolved:
ax25: rcu protect dev->ax25_ptr
syzbot found a lockdep issue [1].
We should remove ax25 RTNL dependency in ax25_setsockopt()
This should also fix a variety of possible UAF in ax25.
[1]
WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted
syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 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
-> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 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
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex);
*** DEADLOCK ***
1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574
stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---(CVE-2025-21812)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't flush non-uploaded STAs
If STA state is pre-moved to AUTHORIZED (such as in IBSS scenarios) and insertion fails, the station is freed. In this case, the driver never knew about the station, so trying to flush it is unexpected and may crash.
Check if the sta was uploaded to the driver before and fix this.(CVE-2025-21828)
In the Linux kernel, the following vulnerability has been resolved:
bpf: avoid holding freeze_mutex during mmap operation
We use map->freeze_mutex to prevent races between map_freeze() and memory mapping BPF map contents with writable permissions. The way we naively do this means we'll hold freeze_mutex for entire duration of all the mm and VMA manipulations, which is completely unnecessary. This can potentially also lead to deadlocks, as reported by syzbot in [0].
So, instead, hold freeze_mutex only during writeability checks, bump (proactively) "write active" count for the map, unlock the mutex and proceed with mmap logic. And only if something went wrong during mmap logic, then undo that "write active" counter increment.
[0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"perf-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-84.0.0.89.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-84.0.0.89.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"perf-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-84.0.0.89.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-84.0.0.89.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-84.0.0.89.oe2403sp1"
}
],
"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\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count. However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n sk_alloc+0x438/0x608\n inet_create+0x4c8/0xcb0\n __sock_create+0x350/0x6b8\n sock_create_kern+0x58/0x78\n udp_sock_create4+0x68/0x398\n udp_sock_create+0x88/0xc8\n tipc_udp_enable+0x5e8/0x848\n __tipc_nl_bearer_enable+0x84c/0xed8\n tipc_nl_bearer_enable+0x38/0x60\n genl_family_rcv_msg_doit+0x170/0x248\n genl_rcv_msg+0x400/0x5b0\n netlink_rcv_skb+0x1dc/0x398\n genl_rcv+0x44/0x68\n netlink_unicast+0x678/0x8b0\n netlink_sendmsg+0x5e4/0x898\n ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3146 [inline]\n packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4091 [inline]\n slab_alloc_node mm/slub.c:4134 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n packet_snd net/packet/af_packet.c:3089 [inline]\n packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer\n\nConsidering that in some extreme cases,\nwhen u_serial driver is accessed by multiple threads,\nThread A is executing the open operation and calling the gs_open,\nThread B is executing the disconnect operation and calling the\ngserial_disconnect function,The port-\u0026gt;port_usb pointer will be set to NULL.\n\nE.g.\n Thread A Thread B\n gs_open() gadget_unbind_driver()\n gs_start_io() composite_disconnect()\n gs_start_rx() gserial_disconnect()\n ... ...\n spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n status = usb_ep_queue() spin_lock(\u0026amp;port-\u0026gt;port_lock)\n spin_lock(\u0026amp;port-\u0026gt;port_lock) port-\u0026gt;port_usb = NULL\n gs_free_requests(port-\u0026gt;port_usb-\u0026gt;in) spin_unlock(\u0026amp;port-\u0026gt;port_lock)\n Crash\n\nThis causes thread A to access a null pointer (port-\u0026gt;port_usb is null)\nwhen calling the gs_free_requests function, causing a crash.\n\nIf port_usb is NULL, the release request will be skipped as it\nwill be done by gserial_disconnect.\n\nSo add a null pointer check to gs_start_io before attempting\nto access the value of the pointer port-\u0026gt;port_usb.\n\nCall trace:\n gs_start_io+0x164/0x25c\n gs_open+0x108/0x13c\n tty_open+0x314/0x638\n chrdev_open+0x1b8/0x258\n do_dentry_open+0x2c4/0x700\n vfs_open+0x2c/0x3c\n path_openat+0xa64/0xc60\n do_filp_open+0xb8/0x164\n do_sys_openat2+0x84/0xf0\n __arm64_sys_openat+0x70/0x9c\n invoke_syscall+0x58/0x114\n el0_svc_common+0x80/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x38/0x68(CVE-2024-56670)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrdma/cxgb4: Prevent potential integer overflow on 32bit\n\nThe \u0026quot;gl-\u0026gt;tot_len\u0026quot; variable is controlled by the user. It comes from\nprocess_responses(). On 32bit systems, the \u0026quot;gl-\u0026gt;tot_len + sizeof(struct\ncpl_pass_accept_req) + sizeof(struct rss_header)\u0026quot; addition could have an\ninteger wrapping bug. Use size_add() to prevent this.(CVE-2024-57973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imx-jpeg: Fix potential error pointer dereference in detach_pm()\n\nThe proble is on the first line:\n\n\tif (jpeg-\u0026gt;pd_dev[i] \u0026amp;\u0026amp; !pm_runtime_suspended(jpeg-\u0026gt;pd_dev[i]))\n\nIf jpeg-\u0026gt;pd_dev[i] is an error pointer, then passing it to\npm_runtime_suspended() will lead to an Oops. The other conditions\ncheck for both error pointers and NULL, but it would be more clear to\nuse the IS_ERR_OR_NULL() check for that.(CVE-2024-57978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Fix assumption that Resolution Multipliers must be in Logical Collections\n\nA report in 2019 by the syzbot fuzzer was found to be connected to two\nerrors in the HID core associated with Resolution Multipliers. One of\nthe errors was fixed by commit ea427a222d8b (\u0026quot;HID: core: Fix deadloop\nin hid_apply_multiplier.\u0026quot;), but the other has not been fixed.\n\nThis error arises because hid_apply_multipler() assumes that every\nResolution Multiplier control is contained in a Logical Collection,\ni.e., there\u0026apos;s no way the routine can ever set multiplier_collection to\nNULL. This is in spite of the fact that the function starts with a\nbig comment saying:\n\n\t * \u0026quot;The Resolution Multiplier control must be contained in the same\n\t * Logical Collection as the control(s) to which it is to be applied.\n\t ...\n\t * If no Logical Collection is\n\t * defined, the Resolution Multiplier is associated with all\n\t * controls in the report.\u0026quot;\n\t * HID Usage Table, v1.12, Section 4.3.1, p30\n\t *\n\t * Thus, search from the current collection upwards until we find a\n\t * logical collection...\n\nThe comment and the code overlook the possibility that none of the\ncollections found may be a Logical Collection.\n\nThe fix is to set the multiplier_collection pointer to NULL if the\ncollection found isn\u0026apos;t a Logical Collection.(CVE-2024-57986)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check\n\nsyzbot has found a type mismatch between a USB pipe and the transfer\nendpoint, which is triggered by the hid-thrustmaster driver[1].\nThere is a number of similar, already fixed issues [2].\nIn this case as in others, implementing check for endpoint type fixes the issue.\n\n[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470\n[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622(CVE-2024-57993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wcn36xx: fix channel survey memory allocation size\n\nKASAN reported a memory allocation issue in wcn-\u0026gt;chan_survey\ndue to incorrect size calculation.\nThis commit uses kcalloc to allocate memory for wcn-\u0026gt;chan_survey,\nensuring proper initialization and preventing the use of uninitialized\nvalues when there are no frames on the channel.(CVE-2024-57997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: add index check to assert to avoid buffer overflow in _read_freq()\n\nPass the freq index to the assert function to make sure\nwe do not read a freq out of the opp-\u0026gt;rates[] table when called\nfrom the indexed variants:\ndev_pm_opp_find_freq_exact_indexed() or\ndev_pm_opp_find_freq_ceil/floor_indexed().\n\nAdd a secondary parameter to the assert function, unused\nfor assert_single_clk() then add assert_clk_index() which\nwill check for the clock index when called from the _indexed()\nfind functions.(CVE-2024-57998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()\n\nIn commit 4284c88fff0e (\u0026quot;PCI: designware-ep: Allow pci_epc_set_bar() update\ninbound map address\u0026quot;) set_bar() was modified to support dynamically\nchanging the backing physical address of a BAR that was already configured.\n\nThis means that set_bar() can be called twice, without ever calling\nclear_bar() (as calling clear_bar() would clear the BAR\u0026apos;s PCI address\nassigned by the host).\n\nThis can only be done if the new BAR size/flags does not differ from the\nexisting BAR configuration. Add these missing checks.\n\nIf we allow set_bar() to set e.g. a new BAR size that differs from the\nexisting BAR size, the new address translation range will be smaller than\nthe BAR size already determined by the host, which would mean that a read\npast the new BAR size would pass the iATU untranslated, which could allow\nthe host to read memory not belonging to the new struct pci_epf_bar.\n\nWhile at it, add comments which clarifies the support for dynamically\nchanging the physical address of a BAR. (Which was also missing.)(CVE-2024-58006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmi: ipmb: Add check devm_kasprintf() returned value\n\ndevm_kasprintf() can return a NULL pointer on failure but this\nreturned value is not checked.(CVE-2024-58051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table\n\nThe function atomctrl_get_smc_sclk_range_table() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to\nretrieve SMU_Info table, it returns NULL which is later dereferenced.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\nIn practice this should never happen as this code only gets called\non polaris chips and the vbios data table will always be present on\nthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix handling of received connection abort\n\nFix the handling of a connection abort that we\u0026apos;ve received. Though the\nabort is at the connection level, it needs propagating to the calls on that\nconnection. Whilst the propagation bit is performed, the calls aren\u0026apos;t then\nwoken up to go and process their termination, and as no further input is\nforthcoming, they just hang.\n\nAlso add some tracing for the logging of connection aborts.(CVE-2024-58053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstaging: media: max96712: fix kernel oops when removing module\n\nThe following kernel oops is thrown when trying to remove the max96712\nmodule:\n\nUnable to handle kernel paging request at virtual address 00007375746174db\nMem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000\n[00007375746174db] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan\n snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2\n imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev\n snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils\n max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse\n [last unloaded: imx8_isi]\nCPU: 0 UID: 0 PID: 754 Comm: rmmod\n\t Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17\nTainted: [C]=CRAP\nHardware name: NXP i.MX95 19X19 board (DT)\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : led_put+0x1c/0x40\nlr : v4l2_subdev_put_privacy_led+0x48/0x58\nsp : ffff80008699bbb0\nx29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000\nx26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\nx23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8\nx20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000\nx11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010\nx8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d\nx5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1\nx2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473\nCall trace:\n led_put+0x1c/0x40\n v4l2_subdev_put_privacy_led+0x48/0x58\n v4l2_async_unregister_subdev+0x2c/0x1a4\n max96712_remove+0x1c/0x38 [max96712]\n i2c_device_remove+0x2c/0x9c\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1cc/0x228\n driver_detach+0x4c/0x98\n bus_remove_driver+0x6c/0xbc\n driver_unregister+0x30/0x60\n i2c_del_driver+0x54/0x64\n max96712_i2c_driver_exit+0x18/0x1d0 [max96712]\n __arm64_sys_delete_module+0x1a4/0x290\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xd8\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x190/0x194\nCode: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)\n---[ end trace 0000000000000000 ]---\n\nThis happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()\nis called again and the data is overwritten to point to sd, instead of\npriv. So, in remove(), the wrong pointer is passed to\nv4l2_async_unregister_subdev(), leading to a crash.(CVE-2024-58054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Fix ida_free call while not allocated\n\nIn the rproc_alloc() function, on error, put_device(\u0026amp;rproc-\u0026gt;dev) is\ncalled, leading to the call of the rproc_type_release() function.\nAn error can occurs before ida_alloc is called.\n\nIn such case in rproc_type_release(), the condition (rproc-\u0026gt;index \u0026gt;= 0) is\ntrue as rproc-\u0026gt;index has been initialized to 0.\nida_free() is called reporting a warning:\n[ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164\n[ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0\n[ 4.188854] ida_free called for id=0 which is not allocated.\n[ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000\n[ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+)\n[ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442\n[ 4.231481] Hardware name: STM32 (Device Tree Support)\n[ 4.236627] Workqueue: events_unbound deferred_probe_work_func\n[ 4.242504] Call trace:\n[ 4.242522] unwind_backtrace from show_stack+0x10/0x14\n[ 4.250218] show_stack from dump_stack_lvl+0x50/0x64\n[ 4.255274] dump_stack_lvl from __warn+0x80/0x12c\n[ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188\n[ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164\n[ 4.270565] ida_free from rproc_type_release+0x38/0x60\n[ 4.275832] rproc_type_release from device_release+0x30/0xa0\n[ 4.281601] device_release from kobject_put+0xc4/0x294\n[ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c\n[ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4\n[ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc]\n[ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc\n\nCalling ida_alloc earlier in rproc_alloc ensures that the rproc-\u0026gt;index is\nproperly set.(CVE-2024-58056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubifs: skip dumping tnc tree when zroot is null\n\nClearing slab cache will free all znode in memory and make\nc-\u0026gt;zroot.znode = NULL, then dumping tnc tree will access\nc-\u0026gt;zroot.znode which cause null pointer dereference.(CVE-2024-58058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: prohibit deactivating all links\n\nIn the internal API this calls this is a WARN_ON, but that\nshould remain since internally we want to know about bugs\nthat may cause this. Prevent deactivating all links in the\ndebugfs write directly.(CVE-2024-58061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: fix memory leaks and invalid access at probe error path\n\nDeinitialize at reverse order when probe fails.\n\nWhen init_sw_vars fails, rtl_deinit_core should not be called, specially\nnow that it destroys the rtl_wq workqueue.\n\nAnd call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be\nleaked.\n\nRemove pci_set_drvdata call as it will already be cleaned up by the core\ndriver code and could lead to memory leaks too. cf. commit 8d450935ae7f\n(\u0026quot;wireless: rtlwifi: remove unnecessary pci_set_drvdata()\u0026quot;) and\ncommit 3d86b93064c7 (\u0026quot;rtlwifi: Fix PCI probe error path orphaned memory\u0026quot;).(CVE-2024-58063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nOPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized\n\nIf a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth\nfrom the OPP table but the bandwidth table was not created because the\ninterconnect properties were missing in the OPP consumer node, the\nkernel will crash with:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000004\n...\npc : _read_bw+0x8/0x10\nlr : _opp_table_find_key+0x9c/0x174\n...\nCall trace:\n _read_bw+0x8/0x10 (P)\n _opp_table_find_key+0x9c/0x174 (L)\n _find_key+0x98/0x168\n dev_pm_opp_find_bw_ceil+0x50/0x88\n...\n\nIn order to fix the crash, create an assert function to check\nif the bandwidth table was created before trying to get a\nbandwidth with _read_bw().(CVE-2024-58068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: prevent adding a device which is already a team device lower\n\nPrevent adding a device which is already a team device lower,\ne.g. adding veth0 if vlan1 was already added and veth0 is a lower of\nvlan1.\n\nThis is not useful in practice and can lead to recursive locking:\n\n$ ip link add veth0 type veth peer name veth1\n$ ip link set veth0 up\n$ ip link set veth1 up\n$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1\n$ ip link add team0 type team\n$ ip link set veth0.1 down\n$ ip link set veth0.1 master team0\nteam0: Port device veth0.1 added\n$ ip link set veth0 down\n$ ip link set veth0 master team0\n\n============================================\nWARNING: possible recursive locking detected\n6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted\n--------------------------------------------\nip/7684 is trying to acquire lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n\nbut task is already holding lock:\nffff888016848e00 (team-\u0026gt;team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)\n\nother info that might help us debug this:\nPossible unsafe locking scenario:\n\nCPU0\n----\nlock(team-\u0026gt;team_lock_key);\nlock(team-\u0026gt;team_lock_key);\n\n*** DEADLOCK ***\n\nMay be due to missing lock nesting notation\n\n2 locks held by ip/7684:\n\nstack backtrace:\nCPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:122)\nprint_deadlock_bug.cold (kernel/locking/lockdep.c:3040)\n__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)\n? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)\nlock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? lock_acquire (kernel/locking/lockdep.c:5822)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\n? fib_sync_up (net/ipv4/fib_semantics.c:2167)\n? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nteam_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\n__dev_notify_flags (net/core/dev.c:8993)\n? __dev_change_flags (net/core/dev.c:8975)\ndev_change_flags (net/core/dev.c:9027)\nvlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)\n? br_device_event (net/bridge/br.c:143)\nnotifier_call_chain (kernel/notifier.c:85)\ncall_netdevice_notifiers_info (net/core/dev.c:1996)\ndev_open (net/core/dev.c:1519 net/core/dev.c:1505)\nteam_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)\n? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)\ndo_set_master (net/core/rtnetlink.c:2917)\ndo_setlink.isra.0 (net/core/rtnetlink.c:3117)(CVE-2024-58071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: remove unused check_buddy_priv\n\nCommit 2461c7d60f9f (\u0026quot;rtlwifi: Update header file\u0026quot;) introduced a global\nlist of private data structures.\n\nLater on, commit 26634c4b1868 (\u0026quot;rtlwifi Modify existing bits to match\nvendor version 2013.02.07\u0026quot;) started adding the private data to that list at\nprobe time and added a hook, check_buddy_priv to find the private data from\na similar device.\n\nHowever, that function was never used.\n\nBesides, though there is a lock for that list, it is never used. And when\nthe probe fails, the private data is never removed from the list. This\nwould cause a second probe to access freed memory.\n\nRemove the unused hook, structures and members, which will prevent the\npotential race condition on the list and its corruption during a second\nprobe when probe fails.(CVE-2024-58072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: handle fastopen disconnect correctly\n\nSyzbot was able to trigger a data stream corruption:\n\n WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n Modules linked in:\n CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\n RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024\n Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 \u0026lt;0f\u0026gt; 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07\n RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293\n RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928\n R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000\n R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000\n FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074\n mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493\n release_sock+0x1aa/0x1f0 net/core/sock.c:3640\n inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]\n __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703\n mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755\n mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x1a6/0x270 net/socket.c:726\n ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583\n ___sys_sendmsg net/socket.c:2637 [inline]\n __sys_sendmsg+0x269/0x350 net/socket.c:2669\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 RIP: 0033:0x7f6e86ebfe69\n Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48\n RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69\n RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003\n RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc\n R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508\n \u0026lt;/TASK\u0026gt;\n\nThe root cause is the bad handling of disconnect() generated internally\nby the MPTCP protocol in case of connect FASTOPEN errors.\n\nAddress the issue increasing the socket disconnect counter even on such\na case, to allow other threads waiting on the same socket lock to\nproperly error out.(CVE-2025-21705)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: consolidate suboption status\n\nMPTCP maintains the received sub-options status is the bitmask carrying\nthe received suboptions and in several bitfields carrying per suboption\nadditional info.\n\nZeroing the bitmask before parsing is not enough to ensure a consistent\nstatus, and the MPTCP code has to additionally clear some bitfiled\ndepending on the actually parsed suboption.\n\nThe above schema is fragile, and syzbot managed to trigger a path where\na relevant bitfield is not cleared/initialized:\n\n BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]\n BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n __mptcp_expand_seq net/mptcp/options.c:1030 [inline]\n mptcp_expand_seq net/mptcp/protocol.h:864 [inline]\n ack_update_msk net/mptcp/options.c:1060 [inline]\n mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209\n tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233\n tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264\n tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916\n tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351\n ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:460 [inline]\n ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567\n __netif_receive_skb_one_core net/core/dev.c:5704 [inline]\n __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817\n process_backlog+0x4ad/0xa50 net/core/dev.c:6149\n __napi_poll+0xe7/0x980 net/core/dev.c:6902\n napi_poll net/core/dev.c:6971 [inline]\n net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093\n handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561\n __do_softirq+0x14/0x1a kernel/softirq.c:595\n do_softirq+0x9a/0x100 kernel/softirq.c:462\n __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]\n __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n neigh_hh_output include/net/neighbour.h:523 [inline]\n neigh_output include/net/neighbour.h:537 [inline]\n ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236\n __ip_finish_output+0x287/0x810\n ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434\n dst_output include/net/dst.h:450 [inline]\n ip_local_out net/ipv4/ip_output.c:130 [inline]\n __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536\n ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550\n __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468\n tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]\n tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829\n __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012\n tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618\n __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130\n __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496\n mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550\n mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889\n mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]\n mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]\n mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]\n mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750\n genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n \n---truncated---(CVE-2025-21707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: enable basic endpoint checking\n\nSyzkaller reports [1] encountering a common issue of utilizing a wrong\nusb endpoint type during URB submitting stage. This, in turn, triggers\na warning shown below.\n\nFor now, enable simple endpoint checking (specifically, bulk and\ninterrupt eps, testing control one is not essential) to mitigate\nthe issue with a view to do other related cosmetic changes later,\nif they are necessary.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv\u0026gt;\nModules linked in:\nCPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617\u0026gt;\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nCode: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8\u0026gt;\nRSP: 0018:ffffc9000441f740 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9\nRDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001\nRBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c\nFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733\n __dev_open+0x2d4/0x4e0 net/core/dev.c:1474\n __dev_change_flags+0x561/0x720 net/core/dev.c:8838\n dev_change_flags+0x8f/0x160 net/core/dev.c:8910\n devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177\n inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003\n sock_do_ioctl+0x116/0x280 net/socket.c:1222\n sock_ioctl+0x22e/0x6c0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fc04ef73d49\n...\n\nThis change has not been tested on real hardware.(CVE-2025-21708)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \u0026quot;pasta\u0026quot; protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn\u0026apos;t influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side\u0026apos;s notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n// tcp_v4_rcv(-\u0026gt;)\n// tcp_rcv_established(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201\u0026lt;-\u0026gt;39222]: tcp_data_queue(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 259909392-\u0026gt;260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n [OFO queue: gap: 65480, len: 0]\n[5201\u0026lt;-\u0026gt;39222]: tcp_data_queue(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_transmit_skb(-\u0026gt;)\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]: tcp_select_window(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: (inet_csk(sk)-\u0026gt;icsk_ack.pending \u0026amp; ICSK_ACK_NOMEM) ? --\u0026gt; TRUE\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n returning 0\n[5201\u0026lt;-\u0026gt;39222]: tcp_select_window(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201\u0026lt;-\u0026gt;39222]: [__tcp_transmit_skb(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: tcp_rcv_established(\u0026lt;-)\n[5201\u0026lt;-\u0026gt;39222]: tcp_v4_rcv(\u0026lt;-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don\u0026apos;t update tp-\u0026gt;rcv_wnd and tp-\u0026gt;rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201\u0026lt;-\u0026gt;39222]: [new_win \u0026gt;= (2 * win_now) ? --\u0026gt; time_to_ack = 0]\n[5201\u0026lt;-\u0026gt;39222]: NOT calling tcp_send_ack()\n [tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160]\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(\u0026lt;-)\n [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n [copied_seq 260040464-\u0026gt;260040464 (0), unread 5559696, qlen 85, ofoq 0]\n returning 6104 bytes\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(\u0026lt;-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp-\u0026gt;rcv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201\u0026lt;-\u0026gt;39222]: tcp_recvmsg_locked(-\u0026gt;)\n[5201\u0026lt;-\u0026gt;39222]: __tcp_cleanup_rbuf(-\u0026gt;) tp-\u0026gt;rcv_wup: 265469200, tp-\u0026gt;rcv_wnd: 262144, tp-\u0026gt;rcv_nxt 265600160\n[5201\u0026lt;-\u0026gt;39222]: [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---(CVE-2025-21710)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/rose: prevent integer overflows in rose_setsockopt()\n\nIn case of possible unpredictably large arguments passed to\nrose_setsockopt() and multiplied by extra values on top of that,\ninteger overflows may occur.\n\nDo the safest minimum and fix these issues by checking the\ncontents of \u0026apos;opt\u0026apos; and returning -EINVAL if they are too large. Also,\nswitch to unsigned int and remove useless check for negative \u0026apos;opt\u0026apos;\nin ROSE_IDLE case.(CVE-2025-21711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix uninit-value in vxlan_vnifilter_dump()\n\nKMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].\n\nIf the length of the netlink message payload is less than\nsizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes\nbeyond the message. This can lead to uninit-value access. Fix this by\nreturning an error in such situations.\n\n[1]\nBUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422\n rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786\n netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317\n __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432\n netlink_dump_start include/linux/netlink.h:340 [inline]\n rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline]\n rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882\n netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542\n rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944\n netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347\n netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4110 [inline]\n slab_alloc_node mm/slub.c:4153 [inline]\n kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205\n kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587\n __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196\n netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:726\n ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637\n __sys_sendmsg net/socket.c:2669 [inline]\n __do_sys_sendmsg net/socket.c:2674 [inline]\n __se_sys_sendmsg net/socket.c:2672 [inline]\n __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672\n x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete intermediate secpath entry in packet offload mode\n\nPackets handled by hardware have added secpath as a way to inform XFRM\ncore code that this path was already handled. That secpath is not needed\nat all after policy is checked and it is removed later in the stack.\n\nHowever, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward),\nthat secpath is not removed and packets which already were handled are reentered\nto the driver TX path with xfrm_offload set.\n\nThe following kernel panic is observed in mlx5 in such case:\n\n mlx5_core 0000:04:00.0 enp4s0f0np0: Link up\n mlx5_core 0000:04:00.1 enp4s0f1np1: Link up\n Initializing XFRM netlink socket\n IPsec XFRM device driver\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor instruction fetch in kernel mode\n #PF: error_code(0x0010) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0010 [#1] PREEMPT SMP\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n RIP: 0010:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 0018:ffffb87380003800 EFLAGS: 00010206\n RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf\n RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00\n RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010\n R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00\n R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e\n FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? show_regs+0x63/0x70\n ? __die_body+0x20/0x60\n ? __die+0x2b/0x40\n ? page_fault_oops+0x15c/0x550\n ? do_user_addr_fault+0x3ed/0x870\n ? exc_page_fault+0x7f/0x190\n ? asm_exc_page_fault+0x27/0x30\n mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core]\n mlx5e_xmit+0x58e/0x1980 [mlx5_core]\n ? __fib_lookup+0x6a/0xb0\n dev_hard_start_xmit+0x82/0x1d0\n sch_direct_xmit+0xfe/0x390\n __dev_queue_xmit+0x6d8/0xee0\n ? __fib_lookup+0x6a/0xb0\n ? internal_add_timer+0x48/0x70\n ? mod_timer+0xe2/0x2b0\n neigh_resolve_output+0x115/0x1b0\n __neigh_update+0x26a/0xc50\n neigh_update+0x14/0x20\n arp_process+0x2cb/0x8e0\n ? __napi_build_skb+0x5e/0x70\n arp_rcv+0x11e/0x1c0\n ? dev_gro_receive+0x574/0x820\n __netif_receive_skb_list_core+0x1cf/0x1f0\n netif_receive_skb_list_internal+0x183/0x2a0\n napi_complete_done+0x76/0x1c0\n mlx5e_napi_poll+0x234/0x7a0 [mlx5_core]\n __napi_poll+0x2d/0x1f0\n net_rx_action+0x1a6/0x370\n ? atomic_notifier_call_chain+0x3b/0x50\n ? irq_int_handler+0x15/0x20 [mlx5_core]\n handle_softirqs+0xb9/0x2f0\n ? handle_irq_event+0x44/0x60\n irq_exit_rcu+0xdb/0x100\n common_interrupt+0x98/0xc0\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_common_interrupt+0x27/0x40\n RIP: 0010:pv_native_safe_halt+0xb/0x10\n Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22\n 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb\n40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8\n RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680\n RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4\n RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70\n R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40\n R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8\n ? default_idle+0x9/0x20\n arch_cpu_idle+0x9/0x10\n default_idle_call+0x29/0xf0\n do_idle+0x1f2/0x240\n cpu_startup_entry+0x2c/0x30\n rest_init+0xe7/0x100\n start_kernel+0x76b/0xb90\n x86_64_start_reservations+0x18/0x30\n x86_64_start_kernel+0xc0/0x110\n ? setup_ghcb+0xe/0x130\n common_startup_64+0x13e/0x141\n \u0026lt;/TASK\u0026gt;\n Modules linked in: esp4_offload esp4 xfrm_interface\nxfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binf\n---truncated---(CVE-2025-21720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()\n\nResolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()\nwhere shifting the constant \u0026quot;1\u0026quot; (of type int) by bitmap-\u0026gt;mapped.pgshift\n(an unsigned long value) could result in undefined behavior.\n\nThe constant \u0026quot;1\u0026quot; defaults to a 32-bit \u0026quot;int\u0026quot;, and when \u0026quot;pgshift\u0026quot; exceeds\n31 (e.g., pgshift = 63) the shift operation overflows, as the result\ncannot be represented in a 32-bit type.\n\nTo resolve this, the constant is updated to \u0026quot;1UL\u0026quot;, promoting it to an\nunsigned long type to match the operand\u0026apos;s type.(CVE-2025-21724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix oops due to unset link speed\n\nIt isn\u0026apos;t guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always\nbe set by the server, so the client must handle any values and then\nprevent oopses like below from happening:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nRIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48\n89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8\ne7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 \u0026lt;48\u0026gt; f7 74 24 18 48 89\nc3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24\nRSP: 0018:ffffc90001817be0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99\nRDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228\nRBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac\nR10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200\nR13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58\nFS: 00007fe27119e740(0000) GS:ffff888148600000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0x159/0x1b0\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? do_error_trap+0x90/0x130\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? exc_divide_error+0x39/0x50\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? asm_exc_divide_error+0x1a/0x20\n ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]\n ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]\n ? seq_read_iter+0x42e/0x790\n seq_read_iter+0x19a/0x790\n proc_reg_read_iter+0xbe/0x110\n ? __pfx_proc_reg_read_iter+0x10/0x10\n vfs_read+0x469/0x570\n ? do_user_addr_fault+0x398/0x760\n ? __pfx_vfs_read+0x10/0x10\n ? find_held_lock+0x8a/0xa0\n ? __pfx_lock_release+0x10/0x10\n ksys_read+0xd3/0x170\n ? __pfx_ksys_read+0x10/0x10\n ? __rcu_read_unlock+0x50/0x270\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe271288911\nCode: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8\n20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 \u0026lt;48\u0026gt; 3d\n00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911\nRDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003\nRBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\n\nFix this by setting cifs_server_iface::speed to a sane value (1Gbps)\nby default when link speed is unset.(CVE-2025-21725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n ...\n padata_reorder\n // processes all remaining\n // requests then breaks\n while (1) {\n if (!padata)\n break;\n ...\n }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t // new request added\n\t\t\t\t list_add\n // sees the new request\n queue_work(reorder_work)\n\t\t\t\t padata_reorder\n\t\t\t\t queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Send signals asynchronously if !preemptible\n\nBPF programs can execute in all kinds of contexts and when a program\nrunning in a non-preemptible context uses the bpf_send_signal() kfunc,\nit will cause issues because this kfunc can sleep.\nChange `irqs_disabled()` to `!preemptible()`.(CVE-2025-21728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: Fix class @block_class\u0026apos;s subsystem refcount leakage\n\nblkcg_fill_root_iostats() iterates over @block_class\u0026apos;s devices by\nclass_dev_iter_(init|next)(), but does not end iterating with\nclass_dev_iter_exit(), so causes the class\u0026apos;s subsystem refcount leakage.\n\nFix by ending the iterating with class_dev_iter_exit().(CVE-2025-21745)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()\n\nWhen getting the IRQ we use k3_udma_glue_tx_get_irq() which returns\nnegative error value on error. So not NULL check is not sufficient\nto deteremine if IRQ is valid. Check that IRQ is greater then zero\nto ensure it is valid.\n\nThere is no issue at probe time but at runtime user can invoke\n.set_channels which results in the following call chain.\nam65_cpsw_set_channels()\n am65_cpsw_nuss_update_tx_rx_chns()\n am65_cpsw_nuss_remove_tx_chns()\n am65_cpsw_nuss_init_tx_chns()\n\nAt this point if am65_cpsw_nuss_init_tx_chns() fails due to\nk3_udma_glue_tx_get_irq() then tx_chn-\u0026gt;irq will be set to a\nnegative value.\n\nThen, at subsequent .set_channels with higher channel count we\nwill attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()\nleading to a kernel warning.\n\nThe issue is present in the original commit that introduced this driver,\nalthough there, am65_cpsw_nuss_update_tx_rx_chns() existed as\nam65_cpsw_nuss_update_tx_chns().(CVE-2025-21799)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix warnings during S3 suspend\n\nThe enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),\nand the later one may call the preempt_schedule_common() function,\nresulting in a thread switch and causing the CPU to be in an interrupt\nenabled state after the enable_gpe_wakeup() function returns, leading\nto the warnings as follow.\n\n[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8\n[ C0] ...\n[ C0] Call Trace:\n[ C0] [\u0026lt;90000000002243b4\u0026gt;] show_stack+0x64/0x188\n[ C0] [\u0026lt;900000000164673c\u0026gt;] dump_stack_lvl+0x60/0x88\n[ C0] [\u0026lt;90000000002687e4\u0026gt;] __warn+0x8c/0x148\n[ C0] [\u0026lt;90000000015e9978\u0026gt;] report_bug+0x1c0/0x2b0\n[ C0] [\u0026lt;90000000016478e4\u0026gt;] do_bp+0x204/0x3b8\n[ C0] [\u0026lt;90000000025b1924\u0026gt;] exception_handlers+0x1924/0x10000\n[ C0] [\u0026lt;9000000000343bbc\u0026gt;] ktime_get+0xbc/0xc8\n[ C0] [\u0026lt;9000000000354c08\u0026gt;] tick_sched_timer+0x30/0xb0\n[ C0] [\u0026lt;90000000003408e0\u0026gt;] __hrtimer_run_queues+0x160/0x378\n[ C0] [\u0026lt;9000000000341f14\u0026gt;] hrtimer_interrupt+0x144/0x388\n[ C0] [\u0026lt;9000000000228348\u0026gt;] constant_timer_interrupt+0x38/0x48\n[ C0] [\u0026lt;90000000002feba4\u0026gt;] __handle_irq_event_percpu+0x64/0x1e8\n[ C0] [\u0026lt;90000000002fed48\u0026gt;] handle_irq_event_percpu+0x20/0x80\n[ C0] [\u0026lt;9000000000306b9c\u0026gt;] handle_percpu_irq+0x5c/0x98\n[ C0] [\u0026lt;90000000002fd4a0\u0026gt;] generic_handle_domain_irq+0x30/0x48\n[ C0] [\u0026lt;9000000000d0c7b0\u0026gt;] handle_cpu_irq+0x70/0xa8\n[ C0] [\u0026lt;9000000001646b30\u0026gt;] handle_loongarch_irq+0x30/0x48\n[ C0] [\u0026lt;9000000001646bc8\u0026gt;] do_vint+0x80/0xe0\n[ C0] [\u0026lt;90000000002aea1c\u0026gt;] finish_task_switch.isra.0+0x8c/0x2a8\n[ C0] [\u0026lt;900000000164e34c\u0026gt;] __schedule+0x314/0xa48\n[ C0] [\u0026lt;900000000164ead8\u0026gt;] schedule+0x58/0xf0\n[ C0] [\u0026lt;9000000000294a2c\u0026gt;] worker_thread+0x224/0x498\n[ C0] [\u0026lt;900000000029d2f0\u0026gt;] kthread+0xf8/0x108\n[ C0] [\u0026lt;9000000000221f28\u0026gt;] ret_from_kernel_thread+0xc/0xa4\n[ C0]\n[ C0] ---[ end trace 0000000000000000 ]---\n\nThe root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect\nacpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause\na thread switch. Since there is no longer concurrent execution during\nloongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()\ndirectly in enable_gpe_wakeup().\n\nThe solution is similar to commit 22db06337f590d01 (\u0026quot;ACPI: sleep: Avoid\nbreaking S3 wakeup due to might_sleep()\u0026quot;).(CVE-2025-21803)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n $ cat /proc/iomem\n 30000000-37ffffff :\n 38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n $ cat /proc/iomem\n 30000000-37ffffff : memory2\n 38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: let net.core.dev_weight always be non-zero\n\nThe following problem was encountered during stability test:\n\n(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\\n\treturned 1, exceeding its budget of 0.\n------------[ cut here ]------------\nlist_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\\n\tnext=ffff88905f746e40.\nWARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\\n\t__list_add_valid_or_report+0xf3/0x130\nCPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+\nRIP: 0010:__list_add_valid_or_report+0xf3/0x130\nCall Trace:\n? __warn+0xcd/0x250\n? __list_add_valid_or_report+0xf3/0x130\nenqueue_to_backlog+0x923/0x1070\nnetif_rx_internal+0x92/0x2b0\n__netif_rx+0x15/0x170\nloopback_xmit+0x2ef/0x450\ndev_hard_start_xmit+0x103/0x490\n__dev_queue_xmit+0xeac/0x1950\nip_finish_output2+0x6cc/0x1620\nip_output+0x161/0x270\nip_push_pending_frames+0x155/0x1a0\nraw_sendmsg+0xe13/0x1550\n__sys_sendto+0x3bf/0x4e0\n__x64_sys_sendto+0xdc/0x1b0\ndo_syscall_64+0x5b/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reproduction command is as follows:\n sysctl -w net.core.dev_weight=0\n ping 127.0.0.1\n\nThis is because when the napi\u0026apos;s weight is set to 0, process_backlog() may\nreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing this\nnapi to be re-polled in net_rx_action() until __do_softirq() times out.\nSince the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can\nbe retriggered in enqueue_to_backlog(), causing this issue.\n\nMaking the napi\u0026apos;s weight always non-zero solves this problem.\n\nTriggering this issue requires system-wide admin (setting is\nnot namespaced).(CVE-2025-21806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: xdp: Disallow attaching device-bound programs in generic mode\n\nDevice-bound programs are used to support RX metadata kfuncs. These\nkfuncs are driver-specific and rely on the driver context to read the\nmetadata. This means they can\u0026apos;t work in generic XDP mode. However, there\nis no check to disallow such programs from being attached in generic\nmode, in which case the metadata kfuncs will be called in an invalid\ncontext, leading to crashes.\n\nFix this by adding a check to disallow attaching device-bound programs\nin generic mode.(CVE-2025-21808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: class: Fix wild pointer dereferences in API class_dev_iter_next()\n\nThere are a potential wild pointer dereferences issue regarding APIs\nclass_dev_iter_(init|next|exit)(), as explained by below typical usage:\n\n// All members of @iter are wild pointers.\nstruct class_dev_iter iter;\n\n// class_dev_iter_init(@iter, @class, ...) checks parameter @class for\n// potential class_to_subsys() error, and it returns void type and does\n// not initialize its output parameter @iter, so caller can not detect\n// the error and continues to invoke class_dev_iter_next(@iter) even if\n// @iter still contains wild pointers.\nclass_dev_iter_init(\u0026amp;iter, ...);\n\n// Dereference these wild pointers in @iter here once suffer the error.\nwhile (dev = class_dev_iter_next(\u0026amp;iter)) { ... };\n\n// Also dereference these wild pointers here.\nclass_dev_iter_exit(\u0026amp;iter);\n\nActually, all callers of these APIs have such usage pattern in kernel tree.\nFix by:\n- Initialize output parameter @iter by memset() in class_dev_iter_init()\n and give callers prompt by pr_crit() for the error.\n- Check if @iter is valid in class_dev_iter_next().(CVE-2025-21810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: protect access to buffers with no active references\n\nnilfs_lookup_dirty_data_buffers(), which iterates through the buffers\nattached to dirty data folios/pages, accesses the attached buffers without\nlocking the folios/pages.\n\nFor data cache, nilfs_clear_folio_dirty() may be called asynchronously\nwhen the file system degenerates to read only, so\nnilfs_lookup_dirty_data_buffers() still has the potential to cause use\nafter free issues when buffers lose the protection of their dirty state\nmidway due to this asynchronous clearing and are unintentionally freed by\ntry_to_free_buffers().\n\nEliminate this race issue by adjusting the lock section in this function.(CVE-2025-21811)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nax25: rcu protect dev-\u0026gt;ax25_ptr\n\nsyzbot found a lockdep issue [1].\n\nWe should remove ax25 RTNL dependency in ax25_setsockopt()\n\nThis should also fix a variety of possible UAF in ax25.\n\n[1]\n\nWARNING: possible circular locking dependency detected\n6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted\n------------------------------------------------------\nsyz.5.1818/12806 is trying to acquire lock:\n ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n\nbut task is already holding lock:\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #1 (sk_lock-AF_AX25){+.+.}-{0:0}:\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n lock_sock_nested+0x48/0x100 net/core/sock.c:3642\n lock_sock include/net/sock.h:1618 [inline]\n ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]\n ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146\n notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85\n __dev_notify_flags+0x207/0x400\n dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026\n dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563\n dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820\n sock_do_ioctl+0x240/0x460 net/socket.c:1234\n sock_ioctl+0x626/0x8e0 net/socket.c:1339\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892\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\n-\u0026gt; #0 (rtnl_mutex){+.+.}-{4:4}:\n check_prev_add kernel/locking/lockdep.c:3161 [inline]\n check_prevs_add kernel/locking/lockdep.c:3280 [inline]\n validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904\n __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735\n ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n do_sock_setsockopt+0x3af/0x720 net/socket.c:2324\n __sys_setsockopt net/socket.c:2349 [inline]\n __do_sys_setsockopt net/socket.c:2355 [inline]\n __se_sys_setsockopt net/socket.c:2352 [inline]\n __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352\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\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(sk_lock-AF_AX25);\n lock(rtnl_mutex);\n lock(sk_lock-AF_AX25);\n lock(rtnl_mutex);\n\n *** DEADLOCK ***\n\n1 lock held by syz.5.1818/12806:\n #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/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_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074\n check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206\n check_prev_add kernel/locking/lockdep.c:3161 [inline]\n check_prevs_add kernel/lockin\n---truncated---(CVE-2025-21812)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: don\u0026apos;t flush non-uploaded STAs\n\nIf STA state is pre-moved to AUTHORIZED (such as in IBSS\nscenarios) and insertion fails, the station is freed.\nIn this case, the driver never knew about the station,\nso trying to flush it is unexpected and may crash.\n\nCheck if the sta was uploaded to the driver before and\nfix this.(CVE-2025-21828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: avoid holding freeze_mutex during mmap operation\n\nWe use map-\u0026gt;freeze_mutex to prevent races between map_freeze() and\nmemory mapping BPF map contents with writable permissions. The way we\nnaively do this means we\u0026apos;ll hold freeze_mutex for entire duration of all\nthe mm and VMA manipulations, which is completely unnecessary. This can\npotentially also lead to deadlocks, as reported by syzbot in [0].\n\nSo, instead, hold freeze_mutex only during writeability checks, bump\n(proactively) \u0026quot;write active\u0026quot; count for the map, unlock the mutex and\nproceed with mmap logic. And only if something went wrong during mmap\nlogic, then undo that \u0026quot;write active\u0026quot; counter increment.\n\n [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/(CVE-2025-21853)",
"id": "OESA-2025-1340",
"modified": "2026-08-06T11:08:26Z",
"published": "2025-03-29T11:08:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1340"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56648"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56670"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57973"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57986"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58006"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58051"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58053"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58061"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58071"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21705"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21707"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21708"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21710"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21716"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21720"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21745"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21799"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21803"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21811"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21812"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21853"
}
],
"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-2024-56642",
"CVE-2024-56648",
"CVE-2024-56670",
"CVE-2024-57973",
"CVE-2024-57978",
"CVE-2024-57986",
"CVE-2024-57993",
"CVE-2024-57997",
"CVE-2024-57998",
"CVE-2024-58006",
"CVE-2024-58034",
"CVE-2024-58051",
"CVE-2024-58052",
"CVE-2024-58053",
"CVE-2024-58054",
"CVE-2024-58056",
"CVE-2024-58058",
"CVE-2024-58061",
"CVE-2024-58063",
"CVE-2024-58068",
"CVE-2024-58071",
"CVE-2024-58072",
"CVE-2025-21687",
"CVE-2025-21705",
"CVE-2025-21707",
"CVE-2025-21708",
"CVE-2025-21710",
"CVE-2025-21711",
"CVE-2025-21715",
"CVE-2025-21716",
"CVE-2025-21720",
"CVE-2025-21724",
"CVE-2025-21725",
"CVE-2025-21726",
"CVE-2025-21727",
"CVE-2025-21728",
"CVE-2025-21745",
"CVE-2025-21799",
"CVE-2025-21803",
"CVE-2025-21804",
"CVE-2025-21806",
"CVE-2025-21808",
"CVE-2025-21810",
"CVE-2025-21811",
"CVE-2025-21812",
"CVE-2025-21828",
"CVE-2025-21853"
]
}
oesa-2025-1409
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()'
All error handling paths lead to 'out' where many resources are freed.
Do it as well here instead of a direct return, otherwise 'log', 'ra' and 'log->one_page_buf' (at least) will leak.(CVE-2021-47660)
In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist
ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate BOOT sectors_per_clusters
When the NTFS BOOT sectors_per_clusters field is > 0x80, it represents a shift value. Make sure that the shift value is not too large before using it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.
This prevents negative shift values and shift values that are larger than the field size.
Prevents this UBSAN error:
UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative(CVE-2022-49553)
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_vma_manager: Add drm_vma_node_allow_once()
Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. Allow drm drivers to call non-refcounted version of drm_vma_node_allow() so that a driver doesn't need to keep track of each drm_vma_node_allow() to call subsequent drm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in cleanup_bearer().
[0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830
[1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix race between element replace and close()
Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element:
// set map[0] = s0 map_update_elem(map, 0, s0)
// drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk)
Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1].
Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced.
[1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063
CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30
The bu ---truncated---(CVE-2024-56664)
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Handle CPU state correctly on hotplug
Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to CPUHP_ONLINE:
Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHP_HRTIMERS_PREPARE once.
This round-trip reveals another issue; cpu_base.online is not set to 1 after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().
Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case.
Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_tcm: Don't free command immediately
Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.(CVE-2024-58055)
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.
This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool.(CVE-2025-21715)
In the Linux kernel, the following vulnerability has been resolved:
net: rose: fix timer races against user threads
Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread.
Add a check and rearm the timers if needed.
BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __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:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>(CVE-2025-21718)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: do not force clear folio if buffer is referenced
Patch series "nilfs2: protect busy buffer heads from being force-cleared".
This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue.
This patch (of 2):
Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur.
One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state:
WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 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
The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be:
WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback.
Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.(CVE-2025-21722)
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:
crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context> invoke_padata_reorder // UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.(CVE-2025-21726)
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)
In the Linux kernel, the following vulnerability has been resolved:
arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).(CVE-2025-21785)
In the Linux kernel, the following vulnerability has been resolved:
vrf: use RCU protection in l3mdev_l3_out()
l3mdev_l3_out() can be called without RCU being held:
raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()
Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.(CVE-2025-21791)
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.
Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:
$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:
$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING
hrtimers are migrated away from the dying CPU to any online target at the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress.
However wakeups can still be performed by the outgoing CPU after CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored.
The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds:
_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)
The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end of its work through cpu_stop_signal_done() and performs a wake up that eventually arms the deadline server timer:
WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: <TASK> start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread
Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU.
This will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Drop unmanaged ELP metric worker
The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context.
Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses.
Directly canceling the metric worker also has various problems:
- cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.
- iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)
The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by:
- creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context
- only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)(CVE-2025-21823)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: prevent opcode speculation
sqe->opcode is used for different tables, make sure we santitise it against speculations.(CVE-2025-21863)
In the Linux kernel, the following vulnerability has been resolved:
uprobes: Reject the shared zeropage in uprobe_write_opcode()
We triggered the following crash in syzkaller tests:
BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2
BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1
The following syzkaller test case can be used to reproduce:
r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)
The cause is that zero pfn is set to the PTE without increasing the RSS count in mfill_atomic_pte_zeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobe_write_opcode()->__replace_page() to unconditional decrease the RSS count and old_folio's refcount.
Therefore, two bugs are introduced:
-
The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count".
-
The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".
There is more, the following warning could also theoretically be triggered:
__replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)
Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after get_user_page_vma_remote().
mingo: Cleaned up the changelog
In the Linux kernel, the following vulnerability has been resolved:
ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up
The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote().
Move dput(upper) after its last use to prevent use-after-free.
BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167
Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK>(CVE-2025-21887)
In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: protect driver attr handlers against module unload
Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held.
Add try_module_get() in these handlers.
For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:
#!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait
Starting with the following warning, several kinds of warnings will appear and the system may become unstable:
------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: <TASK> ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---(CVE-2025-21943)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"perf-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-259.0.0.161.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"perf-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.161.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-259.0.0.161.oe2203sp3"
}
],
"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\nfs/ntfs3: Fix some memory leaks in an error handling path of \u0026apos;log_replay()\u0026apos;\n\nAll error handling paths lead to \u0026apos;out\u0026apos; where many resources are freed.\n\nDo it as well here instead of a direct return, otherwise \u0026apos;log\u0026apos;, \u0026apos;ra\u0026apos; and\n\u0026apos;log-\u0026gt;one_page_buf\u0026apos; (at least) will leak.(CVE-2021-47660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlist: fix a data-race around ep-\u0026gt;rdllist\n\nep_poll() first calls ep_events_available() with no lock held and checks\nif ep-\u0026gt;rdllist is empty by list_empty_careful(), which reads\nrdllist-\u0026gt;prev. Thus all accesses to it need some protection to avoid\nstore/load-tearing.\n\nNote INIT_LIST_HEAD_RCU() already has the annotation for both prev\nand next.\n\nCommit bf3b9f6372c4 (\u0026quot;epoll: Add busy poll support to epoll with socket\nfds.\u0026quot;) added the first lockless ep_events_available(), and commit\nc5a282e9635e (\u0026quot;fs/epoll: reduce the scope of wq lock in epoll_wait()\u0026quot;)\nmade some ep_events_available() calls lockless and added single call under\na lock, finally commit e59d3c64cba6 (\u0026quot;epoll: eliminate unnecessary lock\nfor zero timeout\u0026quot;) made the last ep_events_available() lockless.\n\nBUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait\n\nwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:\n INIT_LIST_HEAD include/linux/list.h:38 [inline]\n list_splice_init include/linux/list.h:492 [inline]\n ep_start_scan fs/eventpoll.c:622 [inline]\n ep_send_events fs/eventpoll.c:1656 [inline]\n ep_poll fs/eventpoll.c:1806 [inline]\n do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:\n list_empty_careful include/linux/list.h:329 [inline]\n ep_events_available fs/eventpoll.c:381 [inline]\n ep_poll fs/eventpoll.c:1797 [inline]\n do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nvalue changed: 0xffff88810480c7d0 -\u0026gt; 0xffff888103c15098\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0026apos;t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u0026lt;ffff8000080849d0\u0026gt;] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u0026lt;ffff8000090667a4\u0026gt;] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u0026lt;ffff8000080106d0\u0026gt;] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u0026lt;ffff80000804a618\u0026gt;] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u0026gt;exit() callback into the new\n cpufreq_dbs_data_release() function. ](CVE-2022-49513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate BOOT sectors_per_clusters\n\nWhen the NTFS BOOT sectors_per_clusters field is \u0026gt; 0x80, it represents a\nshift value. Make sure that the shift value is not too large before using\nit (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.\n\nThis prevents negative shift values and shift values that are larger than\nthe field size.\n\nPrevents this UBSAN error:\n\n UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16\n shift exponent -192 is negative(CVE-2022-49553)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_vma_manager: Add drm_vma_node_allow_once()\n\nCurrently there is no easy way for a drm driver to safely check and allow\ndrm_vma_offset_node for a drm file just once. Allow drm drivers to call\nnon-refcounted version of drm_vma_node_allow() so that a driver doesn\u0026apos;t\nneed to keep track of each drm_vma_node_allow() to call subsequent\ndrm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count. However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n sk_alloc+0x438/0x608\n inet_create+0x4c8/0xcb0\n __sock_create+0x350/0x6b8\n sock_create_kern+0x58/0x78\n udp_sock_create4+0x68/0x398\n udp_sock_create+0x88/0xc8\n tipc_udp_enable+0x5e8/0x848\n __tipc_nl_bearer_enable+0x84c/0xed8\n tipc_nl_bearer_enable+0x38/0x60\n genl_family_rcv_msg_doit+0x170/0x248\n genl_rcv_msg+0x400/0x5b0\n netlink_rcv_skb+0x1dc/0x398\n genl_rcv+0x44/0x68\n netlink_unicast+0x678/0x8b0\n netlink_sendmsg+0x5e4/0x898\n ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix race between element replace and close()\n\nElement replace (with a socket different from the one stored) may race\nwith socket\u0026apos;s close() link popping \u0026amp; unlinking. __sock_map_delete()\nunconditionally unrefs the (wrong) element:\n\n// set map[0] = s0\nmap_update_elem(map, 0, s0)\n\n// drop fd of s0\nclose(s0)\n sock_map_close()\n lock_sock(sk) (s0!)\n sock_map_remove_links(sk)\n link = sk_psock_link_pop()\n sock_map_unlink(sk, link)\n sock_map_delete_from_link\n // replace map[0] with s1\n map_update_elem(map, 0, s1)\n sock_map_update_elem\n (s1!) lock_sock(sk)\n sock_map_update_common\n psock = sk_psock(sk)\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n osk = stab-\u0026gt;sks[idx]\n sock_map_add_link(..., \u0026amp;stab-\u0026gt;sks[idx])\n sock_map_unref(osk, \u0026amp;stab-\u0026gt;sks[idx])\n psock = sk_psock(osk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test(\u0026amp;psock))\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n unlock_sock(sk)\n __sock_map_delete\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n sk = *psk // s1 replaced s0; sk == s1\n if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch\n sk = xchg(psk, NULL)\n if (sk)\n sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle\n psock = sk_psock(sk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test())\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n release_sock(sk)\n\nThen close(map) enqueues bpf_map_free_deferred, which finally calls\nsock_map_free(). This results in some refcount_t warnings along with\na KASAN splat [1].\n\nFix __sock_map_delete(), do not allow sock_map_unref() on elements that\nmay have been replaced.\n\n[1]:\nBUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330\nWrite of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063\n\nCPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\nWorkqueue: events_unbound bpf_map_free_deferred\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n kasan_check_range+0x10f/0x1e0\n sock_map_free+0x10e/0x330\n bpf_map_free_deferred+0x173/0x320\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1202:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x85/0x90\n kmem_cache_alloc_noprof+0x131/0x450\n sk_prot_alloc+0x5b/0x220\n sk_alloc+0x2c/0x870\n unix_create1+0x88/0x8a0\n unix_create+0xc5/0x180\n __sock_create+0x241/0x650\n __sys_socketpair+0x1ce/0x420\n __x64_sys_socketpair+0x92/0x100\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 46:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kmem_cache_free+0x1a1/0x590\n __sk_destruct+0x388/0x5a0\n sk_psock_destroy+0x73e/0xa50\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nThe bu\n---truncated---(CVE-2024-56664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Handle CPU state correctly on hotplug\n\nConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfway\nthrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to\nCPUHP_ONLINE:\n\nSince hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set\nto 1 throughout. However, during a CPU unplug operation, the tick and the\nclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online\nstate, for instance CFS incorrectly assumes that the hrtick is already\nactive, and the chance of the clockevent device to transition to oneshot\nmode is also lost forever for the CPU, unless it goes back to a lower state\nthan CPUHP_HRTIMERS_PREPARE once.\n\nThis round-trip reveals another issue; cpu_base.online is not set to 1\nafter the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().\n\nAside of that, the bulk of the per CPU state is not reset either, which\nmeans there are dangling pointers in the worst case.\n\nAddress this by adding a corresponding startup() callback, which resets the\nstale per CPU state and sets the online flag.\n\n[ tglx: Make the new callback unconditionally available, remove the online\n \tmodification in the prepare() callback and clear the remaining\n \tstate in the starting callback instead of the prepare callback ](CVE-2024-57951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_tcm: Don\u0026apos;t free command immediately\n\nDon\u0026apos;t prematurely free the command. Wait for the status completion of\nthe sense status. It can be freed then. Otherwise we will double-free\nthe command.(CVE-2024-58055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: fix timer races against user threads\n\nRose timers only acquire the socket spinlock, without\nchecking if the socket is owned by one user thread.\n\nAdd a check and rearm the timers if needed.\n\nBUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\nRead of size 2 at addr ffff88802f09b82a by task swapper/0/0\n\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;IRQ\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:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\n call_timer_fn+0x187/0x650 kernel/time/timer.c:1793\n expire_timers kernel/time/timer.c:1844 [inline]\n __run_timers kernel/time/timer.c:2418 [inline]\n __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430\n run_timer_base kernel/time/timer.c:2439 [inline]\n run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n __do_softirq kernel/softirq.c:595 [inline]\n invoke_softirq kernel/softirq.c:435 [inline]\n __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049\n \u0026lt;/IRQ\u0026gt;(CVE-2025-21718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: do not force clear folio if buffer is referenced\n\nPatch series \u0026quot;nilfs2: protect busy buffer heads from being force-cleared\u0026quot;.\n\nThis series fixes the buffer head state inconsistency issues reported by\nsyzbot that occurs when the filesystem is corrupted and falls back to\nread-only, and the associated buffer head use-after-free issue.\n\n\nThis patch (of 2):\n\nSyzbot has reported that after nilfs2 detects filesystem corruption and\nfalls back to read-only, inconsistencies in the buffer state may occur.\n\nOne of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()\nto set a data or metadata buffer as dirty, but it detects that the buffer\nis not in the uptodate state:\n\n WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520\n fs/buffer.c:1177\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598\n nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73\n nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344\n nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\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\nThe other is when nilfs_btree_propagate(), which propagates the dirty\nstate to the ancestor nodes of a b-tree that point to a dirty buffer,\ndetects that the origin buffer is not dirty, even though it should be:\n\n WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089\n nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345\n nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587\n nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006\n nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045\n nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]\n nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]\n nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115\n nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]\n nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\nBoth of these issues are caused by the callbacks that handle the\npage/folio write requests, forcibly clear various states, including the\nworking state of the buffers they hold, at unexpected times when they\ndetect read-only fallback.\n\nFix these issues by checking if the buffer is referenced before clearing\nthe page/folio state, and skipping the clear if it is.(CVE-2025-21722)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n ...\n padata_reorder\n // processes all remaining\n // requests then breaks\n while (1) {\n if (!padata)\n break;\n ...\n }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t // new request added\n\t\t\t\t list_add\n // sees the new request\n queue_work(reorder_work)\n\t\t\t\t padata_reorder\n\t\t\t\t queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array\n\nThe loop that detects/populates cache information already has a bounds\ncheck on the array size but does not account for cache levels with\nseparate data/instructions cache. Fix this by incrementing the index\nfor any populated leaf (instead of any populated level).(CVE-2025-21785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvrf: use RCU protection in l3mdev_l3_out()\n\nl3mdev_l3_out() can be called without RCU being held:\n\nraw_sendmsg()\n ip_push_pending_frames()\n ip_send_skb()\n ip_local_out()\n __ip_local_out()\n l3mdev_ip_out()\n\nAdd rcu_read_lock() / rcu_read_unlock() pair to avoid\na potential UAF.(CVE-2025-21791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n $ cat /proc/iomem\n 30000000-37ffffff :\n 38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n $ cat /proc/iomem\n 30000000-37ffffff : memory2\n 38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING\n\nhrtimers are migrated away from the dying CPU to any online target at\nthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers\nhandling tasks involved in the CPU hotplug forward progress.\n\nHowever wakeups can still be performed by the outgoing CPU after\nCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being\narmed. Depending on several considerations (crystal ball power management\nbased election, earliest timer already enqueued, timer migration enabled or\nnot), the target may eventually be the current CPU even if offline. If that\nhappens, the timer is eventually ignored.\n\nThe most notable example is RCU which had to deal with each and every of\nthose wake-ups by deferring them to an online CPU, along with related\nworkarounds:\n\n_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)\n_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)\n_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)\n\nThe problem isn\u0026apos;t confined to RCU though as the stop machine kthread\n(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end\nof its work through cpu_stop_signal_done() and performs a wake up that\neventually arms the deadline server timer:\n\n WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0\n CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted\n Stopper: multi_cpu_stop+0x0/0x120 \u0026lt;- stop_machine_cpuslocked+0x66/0xc0\n RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n start_dl_timer\n enqueue_dl_entity\n dl_server_start\n enqueue_task_fair\n enqueue_task\n ttwu_do_activate\n try_to_wake_up\n complete\n cpu_stopper_thread\n\nInstead of providing yet another bandaid to work around the situation, fix\nit in the hrtimers infrastructure instead: always migrate away a timer to\nan online target whenever it is enqueued from an offline CPU.\n\nThis will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Drop unmanaged ELP metric worker\n\nThe ELP worker needs to calculate new metric values for all neighbors\n\u0026quot;reachable\u0026quot; over an interface. Some of the used metric sources require\nlocks which might need to sleep. This sleep is incompatible with the RCU\nlist iterator used for the recorded neighbors. The initial approach to work\naround of this problem was to queue another work item per neighbor and then\nrun this in a new context.\n\nEven when this solved the RCU vs might_sleep() conflict, it has a major\nproblems: Nothing was stopping the work item in case it is not needed\nanymore - for example because one of the related interfaces was removed or\nthe batman-adv module was unloaded - resulting in potential invalid memory\naccesses.\n\nDirectly canceling the metric worker also has various problems:\n\n* cancel_work_sync for a to-be-deactivated interface is called with\n rtnl_lock held. But the code in the ELP metric worker also tries to use\n rtnl_lock() - which will never return in this case. This also means that\n cancel_work_sync would never return because it is waiting for the worker\n to finish.\n* iterating over the neighbor list for the to-be-deactivated interface is\n currently done using the RCU specific methods. Which means that it is\n possible to miss items when iterating over it without the associated\n spinlock - a behaviour which is acceptable for a periodic metric check\n but not for a cleanup routine (which must \u0026quot;stop\u0026quot; all still running\n workers)\n\nThe better approch is to get rid of the per interface neighbor metric\nworker and handle everything in the interface worker. The original problems\nare solved by:\n\n* creating a list of neighbors which require new metric information inside\n the RCU protected context, gathering the metric according to the new list\n outside the RCU protected context\n* only use rcu_trylock inside metric gathering code to avoid a deadlock\n when the cancel_delayed_work_sync is called in the interface removal code\n (which is called with the rtnl_lock held)(CVE-2025-21823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: prevent opcode speculation\n\nsqe-\u0026gt;opcode is used for different tables, make sure we santitise it\nagainst speculations.(CVE-2025-21863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuprobes: Reject the shared zeropage in uprobe_write_opcode()\n\nWe triggered the following crash in syzkaller tests:\n\n BUG: Bad page state in process syz.7.38 pfn:1eff3\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3\n flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)\n raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x32/0x50\n bad_page+0x69/0xf0\n free_unref_page_prepare+0x401/0x500\n free_unref_page+0x6d/0x1b0\n uprobe_write_opcode+0x460/0x8e0\n install_breakpoint.part.0+0x51/0x80\n register_for_each_vma+0x1d9/0x2b0\n __uprobe_register+0x245/0x300\n bpf_uprobe_multi_link_attach+0x29b/0x4f0\n link_create+0x1e2/0x280\n __sys_bpf+0x75f/0xac0\n __x64_sys_bpf+0x1a/0x30\n do_syscall_64+0x56/0x100\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\n BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1\n\nThe following syzkaller test case can be used to reproduce:\n\n r2 = creat(\u0026amp;(0x7f0000000000)=\u0026apos;./file0\\x00\u0026apos;, 0x8)\n write$nbd(r2, \u0026amp;(0x7f0000000580)=ANY=[], 0x10)\n r4 = openat(0xffffffffffffff9c, \u0026amp;(0x7f0000000040)=\u0026apos;./file0\\x00\u0026apos;, 0x42, 0x0)\n mmap$IORING_OFF_SQ_RING(\u0026amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)\n r5 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r5, 0xc018aa3f, \u0026amp;(0x7f0000000040)={0xaa, 0x20})\n r6 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r6, 0xc018aa3f, \u0026amp;(0x7f0000000140))\n ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, \u0026amp;(0x7f0000000100)={{\u0026amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})\n ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, \u0026amp;(0x7f0000000000)={{\u0026amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})\n r7 = bpf$PROG_LOAD(0x5, \u0026amp;(0x7f0000000140)={0x2, 0x3, \u0026amp;(0x7f0000000200)=ANY=[@ANYBLOB=\u0026quot;1800000000120000000000000000000095\u0026quot;], \u0026amp;(0x7f0000000000)=\u0026apos;GPL\\x00\u0026apos;, 0x7, 0x0, 0x0, 0x0, 0x0, \u0026apos;\\x00\u0026apos;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)\n bpf$BPF_LINK_CREATE_XDP(0x1c, \u0026amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={\u0026amp;(0x7f0000000080)=\u0026apos;./file0\\x00\u0026apos;, \u0026amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)\n\nThe cause is that zero pfn is set to the PTE without increasing the RSS\ncount in mfill_atomic_pte_zeropage() and the refcount of zero folio does\nnot increase accordingly. Then, the operation on the same pfn is performed\nin uprobe_write_opcode()-\u0026gt;__replace_page() to unconditional decrease the\nRSS count and old_folio\u0026apos;s refcount.\n\nTherefore, two bugs are introduced:\n\n 1. The RSS count is incorrect, when process exit, the check_mm() report\n error \u0026quot;Bad rss-count\u0026quot;.\n\n 2. The reserved folio (zero folio) is freed when folio-\u0026gt;refcount is zero,\n then free_pages_prepare-\u0026gt;free_page_is_bad() report error\n \u0026quot;Bad page state\u0026quot;.\n\nThere is more, the following warning could also theoretically be triggered:\n\n __replace_page()\n -\u0026gt; ...\n -\u0026gt; folio_remove_rmap_pte()\n -\u0026gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)\n\nConsidering that uprobe hit on the zero folio is a very rare case, just\nreject zero old folio immediately after get_user_page_vma_remote().\n\n[ mingo: Cleaned up the changelog ](CVE-2025-21881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up\n\nThe issue was caused by dput(upper) being called before\novl_dentry_update_reval(), while upper-\u0026gt;d_flags was still\naccessed in ovl_dentry_remote().\n\nMove dput(upper) after its last use to prevent use-after-free.\n\nBUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\nBUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:488\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\n ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n ovl_link_up fs/overlayfs/copy_up.c:610 [inline]\n ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170\n ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223\n ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136\n vfs_rename+0xf84/0x20a0 fs/namei.c:4893\n...\n \u0026lt;/TASK\u0026gt;(CVE-2025-21887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: aggregator: protect driver attr handlers against module unload\n\nBoth new_device_store and delete_device_store touch module global\nresources (e.g. gpio_aggregator_lock). To prevent race conditions with\nmodule unload, a reference needs to be held.\n\nAdd try_module_get() in these handlers.\n\nFor new_device_store, this eliminates what appears to be the most dangerous\nscenario: if an id is allocated from gpio_aggregator_idr but\nplatform_device_register has not yet been called or completed, a concurrent\nmodule unload could fail to unregister/delete the device, leaving behind a\ndangling platform device/GPIO forwarder. This can result in various issues.\nThe following simple reproducer demonstrates these problems:\n\n #!/bin/bash\n while :; do\n # note: whether \u0026apos;gpiochip0 0\u0026apos; exists or not does not matter.\n echo \u0026apos;gpiochip0 0\u0026apos; \u0026gt; /sys/bus/platform/drivers/gpio-aggregator/new_device\n done \u0026amp;\n while :; do\n modprobe gpio-aggregator\n modprobe -r gpio-aggregator\n done \u0026amp;\n wait\n\n Starting with the following warning, several kinds of warnings will appear\n and the system may become unstable:\n\n ------------[ cut here ]------------\n list_del corruption, ffff888103e2e980-\u0026gt;next is LIST_POISON1 (dead000000000100)\n WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120\n [...]\n RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? __warn.cold+0x93/0xf2\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? report_bug+0xe6/0x170\n ? __irq_work_queue_local+0x39/0xe0\n ? handle_bug+0x58/0x90\n ? exc_invalid_op+0x13/0x60\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_del_entry_valid_or_report+0xa3/0x120\n gpiod_remove_lookup_table+0x22/0x60\n new_device_store+0x315/0x350 [gpio_aggregator]\n kernfs_fop_write_iter+0x137/0x1f0\n vfs_write+0x262/0x430\n ksys_write+0x60/0xd0\n do_syscall_64+0x6c/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---(CVE-2025-21943)",
"id": "OESA-2025-1409",
"modified": "2026-08-06T11:08:30Z",
"published": "2025-04-11T11:08:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1409"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47660"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49513"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49553"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21943"
}
],
"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-2021-47660",
"CVE-2022-49443",
"CVE-2022-49513",
"CVE-2022-49553",
"CVE-2023-53001",
"CVE-2024-56642",
"CVE-2024-56664",
"CVE-2024-57951",
"CVE-2024-58055",
"CVE-2025-21715",
"CVE-2025-21718",
"CVE-2025-21722",
"CVE-2025-21726",
"CVE-2025-21727",
"CVE-2025-21785",
"CVE-2025-21791",
"CVE-2025-21804",
"CVE-2025-21816",
"CVE-2025-21823",
"CVE-2025-21863",
"CVE-2025-21881",
"CVE-2025-21887",
"CVE-2025-21943"
]
}
oesa-2025-1410
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()'
All error handling paths lead to 'out' where many resources are freed.
Do it as well here instead of a direct return, otherwise 'log', 'ra' and 'log->one_page_buf' (at least) will leak.(CVE-2021-47660)
In the Linux kernel, the following vulnerability has been resolved:
list: fix a data-race around ep->rdllist
ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.
Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next.
Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless.
BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait
write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0xffff88810480c7d0 -> 0xffff888103c15098
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate BOOT sectors_per_clusters
When the NTFS BOOT sectors_per_clusters field is > 0x80, it represents a shift value. Make sure that the shift value is not too large before using it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.
This prevents negative shift values and shift values that are larger than the field size.
Prevents this UBSAN error:
UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative(CVE-2022-49553)
In the Linux kernel, the following vulnerability has been resolved:
drm/drm_vma_manager: Add drm_vma_node_allow_once()
Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. Allow drm drivers to call non-refcounted version of drm_vma_node_allow() so that a driver doesn't need to keep track of each drm_vma_node_allow() to call subsequent drm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free of kernel socket in cleanup_bearer().
syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1]
When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer().
tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.
Let's move the decrement after releasing the socket in cleanup_bearer().
[0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830
[1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix race between element replace and close()
Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element:
// set map[0] = s0 map_update_elem(map, 0, s0)
// drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk)
Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1].
Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced.
[1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063
CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30
The bu ---truncated---(CVE-2024-56664)
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Handle CPU state correctly on hotplug
Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to CPUHP_ONLINE:
Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHP_HRTIMERS_PREPARE once.
This round-trip reveals another issue; cpu_base.online is not set to 1 after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().
Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case.
Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag.
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_tcm: Don't free command immediately
Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.(CVE-2024-58055)
In the Linux kernel, the following vulnerability has been resolved:
net: davicom: fix UAF in dm9000_drv_remove
dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.
This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").
This bug is detected by our static analysis tool.(CVE-2025-21715)
In the Linux kernel, the following vulnerability has been resolved:
net: rose: fix timer races against user threads
Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread.
Add a check and rearm the timers if needed.
BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __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:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>(CVE-2025-21718)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: do not force clear folio if buffer is referenced
Patch series "nilfs2: protect busy buffer heads from being force-cleared".
This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue.
This patch (of 2):
Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur.
One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state:
WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 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
The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be:
WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>
Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback.
Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.(CVE-2025-21722)
In the Linux kernel, the following vulnerability has been resolved:
padata: avoid UAF for reorder_work
Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:
crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }
padata_do_serial
// new request added
list_add
// sees the new request
queue_work(reorder_work)
padata_reorder
queue_work_on(squeue->work)
...
<kworker context>
padata_serial_worker
// completes new request,
// no more outstanding
// requests
crypto_del_alg
// free pd
<kworker context> invoke_padata_reorder // UAF of pd
To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.(CVE-2025-21726)
In the Linux kernel, the following vulnerability has been resolved:
padata: fix UAF in padata_reorder
A bug was found when run ltp test:
BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206
CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0
If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01).
This can be explained as bellow:
pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF }
In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF.
As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish.
[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)
In the Linux kernel, the following vulnerability has been resolved:
arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array
The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).(CVE-2025-21785)
In the Linux kernel, the following vulnerability has been resolved:
vrf: use RCU protection in l3mdev_l3_out()
l3mdev_l3_out() can be called without RCU being held:
raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out()
Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF.(CVE-2025-21791)
In the Linux kernel, the following vulnerability has been resolved:
PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()
The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.
Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:
$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :
Sometimes, garbage may appear after the colon.
In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.
Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:
$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3
In the Linux kernel, the following vulnerability has been resolved:
hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING
hrtimers are migrated away from the dying CPU to any online target at the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress.
However wakeups can still be performed by the outgoing CPU after CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored.
The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds:
_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)
The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end of its work through cpu_stop_signal_done() and performs a wake up that eventually arms the deadline server timer:
WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: <TASK> start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread
Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU.
This will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Drop unmanaged ELP metric worker
The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context.
Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses.
Directly canceling the metric worker also has various problems:
- cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.
- iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)
The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by:
- creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context
- only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)(CVE-2025-21823)
In the Linux kernel, the following vulnerability has been resolved:
io_uring: prevent opcode speculation
sqe->opcode is used for different tables, make sure we santitise it against speculations.(CVE-2025-21863)
In the Linux kernel, the following vulnerability has been resolved:
uprobes: Reject the shared zeropage in uprobe_write_opcode()
We triggered the following crash in syzkaller tests:
BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2
BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1
The following syzkaller test case can be used to reproduce:
r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)
The cause is that zero pfn is set to the PTE without increasing the RSS count in mfill_atomic_pte_zeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobe_write_opcode()->__replace_page() to unconditional decrease the RSS count and old_folio's refcount.
Therefore, two bugs are introduced:
-
The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count".
-
The reserved folio (zero folio) is freed when folio->refcount is zero, then free_pages_prepare->free_page_is_bad() report error "Bad page state".
There is more, the following warning could also theoretically be triggered:
__replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)
Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after get_user_page_vma_remote().
mingo: Cleaned up the changelog
In the Linux kernel, the following vulnerability has been resolved:
ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up
The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote().
Move dput(upper) after its last use to prevent use-after-free.
BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167
Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK>(CVE-2025-21887)
In the Linux kernel, the following vulnerability has been resolved:
gpio: aggregator: protect driver attr handlers against module unload
Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held.
Add try_module_get() in these handlers.
For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:
#!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait
Starting with the following warning, several kinds of warnings will appear and the system may become unstable:
------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: <TASK> ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---(CVE-2025-21943)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-259.0.0.162.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-259.0.0.162.oe2203sp4"
}
],
"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\nfs/ntfs3: Fix some memory leaks in an error handling path of \u0026apos;log_replay()\u0026apos;\n\nAll error handling paths lead to \u0026apos;out\u0026apos; where many resources are freed.\n\nDo it as well here instead of a direct return, otherwise \u0026apos;log\u0026apos;, \u0026apos;ra\u0026apos; and\n\u0026apos;log-\u0026gt;one_page_buf\u0026apos; (at least) will leak.(CVE-2021-47660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlist: fix a data-race around ep-\u0026gt;rdllist\n\nep_poll() first calls ep_events_available() with no lock held and checks\nif ep-\u0026gt;rdllist is empty by list_empty_careful(), which reads\nrdllist-\u0026gt;prev. Thus all accesses to it need some protection to avoid\nstore/load-tearing.\n\nNote INIT_LIST_HEAD_RCU() already has the annotation for both prev\nand next.\n\nCommit bf3b9f6372c4 (\u0026quot;epoll: Add busy poll support to epoll with socket\nfds.\u0026quot;) added the first lockless ep_events_available(), and commit\nc5a282e9635e (\u0026quot;fs/epoll: reduce the scope of wq lock in epoll_wait()\u0026quot;)\nmade some ep_events_available() calls lockless and added single call under\na lock, finally commit e59d3c64cba6 (\u0026quot;epoll: eliminate unnecessary lock\nfor zero timeout\u0026quot;) made the last ep_events_available() lockless.\n\nBUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait\n\nwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:\n INIT_LIST_HEAD include/linux/list.h:38 [inline]\n list_splice_init include/linux/list.h:492 [inline]\n ep_start_scan fs/eventpoll.c:622 [inline]\n ep_send_events fs/eventpoll.c:1656 [inline]\n ep_poll fs/eventpoll.c:1806 [inline]\n do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:\n list_empty_careful include/linux/list.h:329 [inline]\n ep_events_available fs/eventpoll.c:381 [inline]\n ep_poll fs/eventpoll.c:1797 [inline]\n do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nvalue changed: 0xffff88810480c7d0 -\u0026gt; 0xffff888103c15098\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0026apos;t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n Modules linked in:\n CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : debug_print_object+0xb8/0x100\n lr : debug_print_object+0xb8/0x100\n sp : ffff80001dfcf9a0\n x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n Call trace:\n debug_print_object+0xb8/0x100\n __debug_check_no_obj_freed+0x1d0/0x25c\n debug_check_no_obj_freed+0x24/0xa0\n kfree+0x11c/0x440\n cpufreq_dbs_governor_exit+0xa8/0xac\n cpufreq_exit_governor+0x44/0x90\n cpufreq_set_policy+0x29c/0x570\n store_scaling_governor+0x110/0x154\n store+0xb0/0xe0\n sysfs_kf_write+0x58/0x84\n kernfs_fop_write_iter+0x12c/0x1c0\n new_sync_write+0xf0/0x18c\n vfs_write+0x1cc/0x220\n ksys_write+0x74/0x100\n __arm64_sys_write+0x28/0x3c\n invoke_syscall.constprop.0+0x58/0xf0\n do_el0_svc+0x70/0x170\n el0_svc+0x54/0x190\n el0t_64_sync_handler+0xa4/0x130\n el0t_64_sync+0x1a0/0x1a4\n irq event stamp: 189006\n hardirqs last enabled at (189005): [\u0026lt;ffff8000080849d0\u0026gt;] finish_task_switch.isra.0+0xe0/0x2c0\n hardirqs last disabled at (189006): [\u0026lt;ffff8000090667a4\u0026gt;] el1_dbg+0x24/0xa0\n softirqs last enabled at (188966): [\u0026lt;ffff8000080106d0\u0026gt;] __do_softirq+0x4b0/0x6a0\n softirqs last disabled at (188957): [\u0026lt;ffff80000804a618\u0026gt;] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n cpufreq_dbs_governor_exit() now, it is also necessary to put the\n invocation of the governor -\u0026gt;exit() callback into the new\n cpufreq_dbs_data_release() function. ](CVE-2022-49513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate BOOT sectors_per_clusters\n\nWhen the NTFS BOOT sectors_per_clusters field is \u0026gt; 0x80, it represents a\nshift value. Make sure that the shift value is not too large before using\nit (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.\n\nThis prevents negative shift values and shift values that are larger than\nthe field size.\n\nPrevents this UBSAN error:\n\n UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16\n shift exponent -192 is negative(CVE-2022-49553)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_vma_manager: Add drm_vma_node_allow_once()\n\nCurrently there is no easy way for a drm driver to safely check and allow\ndrm_vma_offset_node for a drm file just once. Allow drm drivers to call\nnon-refcounted version of drm_vma_node_allow() so that a driver doesn\u0026apos;t\nneed to keep track of each drm_vma_node_allow() to call subsequent\ndrm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count. However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n sk_alloc+0x438/0x608\n inet_create+0x4c8/0xcb0\n __sock_create+0x350/0x6b8\n sock_create_kern+0x58/0x78\n udp_sock_create4+0x68/0x398\n udp_sock_create+0x88/0xc8\n tipc_udp_enable+0x5e8/0x848\n __tipc_nl_bearer_enable+0x84c/0xed8\n tipc_nl_bearer_enable+0x38/0x60\n genl_family_rcv_msg_doit+0x170/0x248\n genl_rcv_msg+0x400/0x5b0\n netlink_rcv_skb+0x1dc/0x398\n genl_rcv+0x44/0x68\n netlink_unicast+0x678/0x8b0\n netlink_sendmsg+0x5e4/0x898\n ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix race between element replace and close()\n\nElement replace (with a socket different from the one stored) may race\nwith socket\u0026apos;s close() link popping \u0026amp; unlinking. __sock_map_delete()\nunconditionally unrefs the (wrong) element:\n\n// set map[0] = s0\nmap_update_elem(map, 0, s0)\n\n// drop fd of s0\nclose(s0)\n sock_map_close()\n lock_sock(sk) (s0!)\n sock_map_remove_links(sk)\n link = sk_psock_link_pop()\n sock_map_unlink(sk, link)\n sock_map_delete_from_link\n // replace map[0] with s1\n map_update_elem(map, 0, s1)\n sock_map_update_elem\n (s1!) lock_sock(sk)\n sock_map_update_common\n psock = sk_psock(sk)\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n osk = stab-\u0026gt;sks[idx]\n sock_map_add_link(..., \u0026amp;stab-\u0026gt;sks[idx])\n sock_map_unref(osk, \u0026amp;stab-\u0026gt;sks[idx])\n psock = sk_psock(osk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test(\u0026amp;psock))\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n unlock_sock(sk)\n __sock_map_delete\n spin_lock(\u0026amp;stab-\u0026gt;lock)\n sk = *psk // s1 replaced s0; sk == s1\n if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch\n sk = xchg(psk, NULL)\n if (sk)\n sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle\n psock = sk_psock(sk)\n sk_psock_put(sk, psock)\n if (refcount_dec_and_test())\n sk_psock_drop(sk, psock)\n spin_unlock(\u0026amp;stab-\u0026gt;lock)\n release_sock(sk)\n\nThen close(map) enqueues bpf_map_free_deferred, which finally calls\nsock_map_free(). This results in some refcount_t warnings along with\na KASAN splat [1].\n\nFix __sock_map_delete(), do not allow sock_map_unref() on elements that\nmay have been replaced.\n\n[1]:\nBUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330\nWrite of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063\n\nCPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\nWorkqueue: events_unbound bpf_map_free_deferred\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n kasan_check_range+0x10f/0x1e0\n sock_map_free+0x10e/0x330\n bpf_map_free_deferred+0x173/0x320\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1202:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x85/0x90\n kmem_cache_alloc_noprof+0x131/0x450\n sk_prot_alloc+0x5b/0x220\n sk_alloc+0x2c/0x870\n unix_create1+0x88/0x8a0\n unix_create+0xc5/0x180\n __sock_create+0x241/0x650\n __sys_socketpair+0x1ce/0x420\n __x64_sys_socketpair+0x92/0x100\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 46:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kmem_cache_free+0x1a1/0x590\n __sk_destruct+0x388/0x5a0\n sk_psock_destroy+0x73e/0xa50\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nThe bu\n---truncated---(CVE-2024-56664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Handle CPU state correctly on hotplug\n\nConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfway\nthrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to\nCPUHP_ONLINE:\n\nSince hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set\nto 1 throughout. However, during a CPU unplug operation, the tick and the\nclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online\nstate, for instance CFS incorrectly assumes that the hrtick is already\nactive, and the chance of the clockevent device to transition to oneshot\nmode is also lost forever for the CPU, unless it goes back to a lower state\nthan CPUHP_HRTIMERS_PREPARE once.\n\nThis round-trip reveals another issue; cpu_base.online is not set to 1\nafter the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().\n\nAside of that, the bulk of the per CPU state is not reset either, which\nmeans there are dangling pointers in the worst case.\n\nAddress this by adding a corresponding startup() callback, which resets the\nstale per CPU state and sets the online flag.\n\n[ tglx: Make the new callback unconditionally available, remove the online\n \tmodification in the prepare() callback and clear the remaining\n \tstate in the starting callback instead of the prepare callback ](CVE-2024-57951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_tcm: Don\u0026apos;t free command immediately\n\nDon\u0026apos;t prematurely free the command. Wait for the status completion of\nthe sense status. It can be freed then. Otherwise we will double-free\nthe command.(CVE-2024-58055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: fix timer races against user threads\n\nRose timers only acquire the socket spinlock, without\nchecking if the socket is owned by one user thread.\n\nAdd a check and rearm the timers if needed.\n\nBUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\nRead of size 2 at addr ffff88802f09b82a by task swapper/0/0\n\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;IRQ\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:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\n call_timer_fn+0x187/0x650 kernel/time/timer.c:1793\n expire_timers kernel/time/timer.c:1844 [inline]\n __run_timers kernel/time/timer.c:2418 [inline]\n __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430\n run_timer_base kernel/time/timer.c:2439 [inline]\n run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n __do_softirq kernel/softirq.c:595 [inline]\n invoke_softirq kernel/softirq.c:435 [inline]\n __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049\n \u0026lt;/IRQ\u0026gt;(CVE-2025-21718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: do not force clear folio if buffer is referenced\n\nPatch series \u0026quot;nilfs2: protect busy buffer heads from being force-cleared\u0026quot;.\n\nThis series fixes the buffer head state inconsistency issues reported by\nsyzbot that occurs when the filesystem is corrupted and falls back to\nread-only, and the associated buffer head use-after-free issue.\n\n\nThis patch (of 2):\n\nSyzbot has reported that after nilfs2 detects filesystem corruption and\nfalls back to read-only, inconsistencies in the buffer state may occur.\n\nOne of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()\nto set a data or metadata buffer as dirty, but it detects that the buffer\nis not in the uptodate state:\n\n WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520\n fs/buffer.c:1177\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598\n nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73\n nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344\n nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\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\nThe other is when nilfs_btree_propagate(), which propagates the dirty\nstate to the ancestor nodes of a b-tree that point to a dirty buffer,\ndetects that the origin buffer is not dirty, even though it should be:\n\n WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089\n nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345\n nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587\n nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006\n nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045\n nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]\n nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]\n nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115\n nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479\n nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]\n nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\nBoth of these issues are caused by the callbacks that handle the\npage/folio write requests, forcibly clear various states, including the\nworking state of the buffers they hold, at unexpected times when they\ndetect read-only fallback.\n\nFix these issues by checking if the buffer is referenced before clearing\nthe page/folio state, and skipping the clear if it is.(CVE-2025-21722)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n ...\n padata_reorder\n // processes all remaining\n // requests then breaks\n while (1) {\n if (!padata)\n break;\n ...\n }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t // new request added\n\t\t\t\t list_add\n // sees the new request\n queue_work(reorder_work)\n\t\t\t\t padata_reorder\n\t\t\t\t queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array\n\nThe loop that detects/populates cache information already has a bounds\ncheck on the array size but does not account for cache levels with\nseparate data/instructions cache. Fix this by incrementing the index\nfor any populated leaf (instead of any populated level).(CVE-2025-21785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvrf: use RCU protection in l3mdev_l3_out()\n\nl3mdev_l3_out() can be called without RCU being held:\n\nraw_sendmsg()\n ip_push_pending_frames()\n ip_send_skb()\n ip_local_out()\n __ip_local_out()\n l3mdev_ip_out()\n\nAdd rcu_read_lock() / rcu_read_unlock() pair to avoid\na potential UAF.(CVE-2025-21791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n $ cat /proc/iomem\n 30000000-37ffffff :\n 38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n $ cat /proc/iomem\n 30000000-37ffffff : memory2\n 38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING\n\nhrtimers are migrated away from the dying CPU to any online target at\nthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers\nhandling tasks involved in the CPU hotplug forward progress.\n\nHowever wakeups can still be performed by the outgoing CPU after\nCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being\narmed. Depending on several considerations (crystal ball power management\nbased election, earliest timer already enqueued, timer migration enabled or\nnot), the target may eventually be the current CPU even if offline. If that\nhappens, the timer is eventually ignored.\n\nThe most notable example is RCU which had to deal with each and every of\nthose wake-ups by deferring them to an online CPU, along with related\nworkarounds:\n\n_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)\n_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)\n_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)\n\nThe problem isn\u0026apos;t confined to RCU though as the stop machine kthread\n(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end\nof its work through cpu_stop_signal_done() and performs a wake up that\neventually arms the deadline server timer:\n\n WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0\n CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted\n Stopper: multi_cpu_stop+0x0/0x120 \u0026lt;- stop_machine_cpuslocked+0x66/0xc0\n RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n start_dl_timer\n enqueue_dl_entity\n dl_server_start\n enqueue_task_fair\n enqueue_task\n ttwu_do_activate\n try_to_wake_up\n complete\n cpu_stopper_thread\n\nInstead of providing yet another bandaid to work around the situation, fix\nit in the hrtimers infrastructure instead: always migrate away a timer to\nan online target whenever it is enqueued from an offline CPU.\n\nThis will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Drop unmanaged ELP metric worker\n\nThe ELP worker needs to calculate new metric values for all neighbors\n\u0026quot;reachable\u0026quot; over an interface. Some of the used metric sources require\nlocks which might need to sleep. This sleep is incompatible with the RCU\nlist iterator used for the recorded neighbors. The initial approach to work\naround of this problem was to queue another work item per neighbor and then\nrun this in a new context.\n\nEven when this solved the RCU vs might_sleep() conflict, it has a major\nproblems: Nothing was stopping the work item in case it is not needed\nanymore - for example because one of the related interfaces was removed or\nthe batman-adv module was unloaded - resulting in potential invalid memory\naccesses.\n\nDirectly canceling the metric worker also has various problems:\n\n* cancel_work_sync for a to-be-deactivated interface is called with\n rtnl_lock held. But the code in the ELP metric worker also tries to use\n rtnl_lock() - which will never return in this case. This also means that\n cancel_work_sync would never return because it is waiting for the worker\n to finish.\n* iterating over the neighbor list for the to-be-deactivated interface is\n currently done using the RCU specific methods. Which means that it is\n possible to miss items when iterating over it without the associated\n spinlock - a behaviour which is acceptable for a periodic metric check\n but not for a cleanup routine (which must \u0026quot;stop\u0026quot; all still running\n workers)\n\nThe better approch is to get rid of the per interface neighbor metric\nworker and handle everything in the interface worker. The original problems\nare solved by:\n\n* creating a list of neighbors which require new metric information inside\n the RCU protected context, gathering the metric according to the new list\n outside the RCU protected context\n* only use rcu_trylock inside metric gathering code to avoid a deadlock\n when the cancel_delayed_work_sync is called in the interface removal code\n (which is called with the rtnl_lock held)(CVE-2025-21823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: prevent opcode speculation\n\nsqe-\u0026gt;opcode is used for different tables, make sure we santitise it\nagainst speculations.(CVE-2025-21863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuprobes: Reject the shared zeropage in uprobe_write_opcode()\n\nWe triggered the following crash in syzkaller tests:\n\n BUG: Bad page state in process syz.7.38 pfn:1eff3\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3\n flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)\n raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x32/0x50\n bad_page+0x69/0xf0\n free_unref_page_prepare+0x401/0x500\n free_unref_page+0x6d/0x1b0\n uprobe_write_opcode+0x460/0x8e0\n install_breakpoint.part.0+0x51/0x80\n register_for_each_vma+0x1d9/0x2b0\n __uprobe_register+0x245/0x300\n bpf_uprobe_multi_link_attach+0x29b/0x4f0\n link_create+0x1e2/0x280\n __sys_bpf+0x75f/0xac0\n __x64_sys_bpf+0x1a/0x30\n do_syscall_64+0x56/0x100\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\n BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1\n\nThe following syzkaller test case can be used to reproduce:\n\n r2 = creat(\u0026amp;(0x7f0000000000)=\u0026apos;./file0\\x00\u0026apos;, 0x8)\n write$nbd(r2, \u0026amp;(0x7f0000000580)=ANY=[], 0x10)\n r4 = openat(0xffffffffffffff9c, \u0026amp;(0x7f0000000040)=\u0026apos;./file0\\x00\u0026apos;, 0x42, 0x0)\n mmap$IORING_OFF_SQ_RING(\u0026amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)\n r5 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r5, 0xc018aa3f, \u0026amp;(0x7f0000000040)={0xaa, 0x20})\n r6 = userfaultfd(0x80801)\n ioctl$UFFDIO_API(r6, 0xc018aa3f, \u0026amp;(0x7f0000000140))\n ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, \u0026amp;(0x7f0000000100)={{\u0026amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})\n ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, \u0026amp;(0x7f0000000000)={{\u0026amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})\n r7 = bpf$PROG_LOAD(0x5, \u0026amp;(0x7f0000000140)={0x2, 0x3, \u0026amp;(0x7f0000000200)=ANY=[@ANYBLOB=\u0026quot;1800000000120000000000000000000095\u0026quot;], \u0026amp;(0x7f0000000000)=\u0026apos;GPL\\x00\u0026apos;, 0x7, 0x0, 0x0, 0x0, 0x0, \u0026apos;\\x00\u0026apos;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)\n bpf$BPF_LINK_CREATE_XDP(0x1c, \u0026amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={\u0026amp;(0x7f0000000080)=\u0026apos;./file0\\x00\u0026apos;, \u0026amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)\n\nThe cause is that zero pfn is set to the PTE without increasing the RSS\ncount in mfill_atomic_pte_zeropage() and the refcount of zero folio does\nnot increase accordingly. Then, the operation on the same pfn is performed\nin uprobe_write_opcode()-\u0026gt;__replace_page() to unconditional decrease the\nRSS count and old_folio\u0026apos;s refcount.\n\nTherefore, two bugs are introduced:\n\n 1. The RSS count is incorrect, when process exit, the check_mm() report\n error \u0026quot;Bad rss-count\u0026quot;.\n\n 2. The reserved folio (zero folio) is freed when folio-\u0026gt;refcount is zero,\n then free_pages_prepare-\u0026gt;free_page_is_bad() report error\n \u0026quot;Bad page state\u0026quot;.\n\nThere is more, the following warning could also theoretically be triggered:\n\n __replace_page()\n -\u0026gt; ...\n -\u0026gt; folio_remove_rmap_pte()\n -\u0026gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)\n\nConsidering that uprobe hit on the zero folio is a very rare case, just\nreject zero old folio immediately after get_user_page_vma_remote().\n\n[ mingo: Cleaned up the changelog ](CVE-2025-21881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up\n\nThe issue was caused by dput(upper) being called before\novl_dentry_update_reval(), while upper-\u0026gt;d_flags was still\naccessed in ovl_dentry_remote().\n\nMove dput(upper) after its last use to prevent use-after-free.\n\nBUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\nBUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:488\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\n ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n ovl_link_up fs/overlayfs/copy_up.c:610 [inline]\n ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170\n ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223\n ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136\n vfs_rename+0xf84/0x20a0 fs/namei.c:4893\n...\n \u0026lt;/TASK\u0026gt;(CVE-2025-21887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: aggregator: protect driver attr handlers against module unload\n\nBoth new_device_store and delete_device_store touch module global\nresources (e.g. gpio_aggregator_lock). To prevent race conditions with\nmodule unload, a reference needs to be held.\n\nAdd try_module_get() in these handlers.\n\nFor new_device_store, this eliminates what appears to be the most dangerous\nscenario: if an id is allocated from gpio_aggregator_idr but\nplatform_device_register has not yet been called or completed, a concurrent\nmodule unload could fail to unregister/delete the device, leaving behind a\ndangling platform device/GPIO forwarder. This can result in various issues.\nThe following simple reproducer demonstrates these problems:\n\n #!/bin/bash\n while :; do\n # note: whether \u0026apos;gpiochip0 0\u0026apos; exists or not does not matter.\n echo \u0026apos;gpiochip0 0\u0026apos; \u0026gt; /sys/bus/platform/drivers/gpio-aggregator/new_device\n done \u0026amp;\n while :; do\n modprobe gpio-aggregator\n modprobe -r gpio-aggregator\n done \u0026amp;\n wait\n\n Starting with the following warning, several kinds of warnings will appear\n and the system may become unstable:\n\n ------------[ cut here ]------------\n list_del corruption, ffff888103e2e980-\u0026gt;next is LIST_POISON1 (dead000000000100)\n WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120\n [...]\n RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? __warn.cold+0x93/0xf2\n ? __list_del_entry_valid_or_report+0xa3/0x120\n ? report_bug+0xe6/0x170\n ? __irq_work_queue_local+0x39/0xe0\n ? handle_bug+0x58/0x90\n ? exc_invalid_op+0x13/0x60\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_del_entry_valid_or_report+0xa3/0x120\n gpiod_remove_lookup_table+0x22/0x60\n new_device_store+0x315/0x350 [gpio_aggregator]\n kernfs_fop_write_iter+0x137/0x1f0\n vfs_write+0x262/0x430\n ksys_write+0x60/0xd0\n do_syscall_64+0x6c/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---(CVE-2025-21943)",
"id": "OESA-2025-1410",
"modified": "2026-08-06T11:08:30Z",
"published": "2025-04-11T11:08:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1410"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47660"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49443"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49513"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49553"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21727"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21804"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21943"
}
],
"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-2021-47660",
"CVE-2022-49443",
"CVE-2022-49513",
"CVE-2022-49553",
"CVE-2023-53001",
"CVE-2024-56642",
"CVE-2024-56664",
"CVE-2024-57951",
"CVE-2024-58055",
"CVE-2025-21715",
"CVE-2025-21718",
"CVE-2025-21722",
"CVE-2025-21726",
"CVE-2025-21727",
"CVE-2025-21785",
"CVE-2025-21791",
"CVE-2025-21804",
"CVE-2025-21816",
"CVE-2025-21823",
"CVE-2025-21863",
"CVE-2025-21881",
"CVE-2025-21887",
"CVE-2025-21943"
]
}
RHSA-2020:4431
Vulnerability from csaf_redhat - Published: 2020-11-04 00:53 - Updated: 2026-08-07 02:37A use-after-free vulnerability was found in the Linux kernel's padata subsystem, in the `padata_reorder()` function. Caused by improper synchronization controls, this vulnerability can occur when a reference-counted data structure (`pd`) is decremented in one thread, freeing it, while another thread still holds a pointer to it and attempts to access it via `padata_find_next()`. This vulnerability can lead to system instability, denial of service, and potential privilege escalation.
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.
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.