Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-21791 (GCVE-0-2025-21791)
Vulnerability from cvelistv5 – Published: 2025-02-27 02:18 – Updated: 2026-08-05 11:54- CWE-416 - Use After Free
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < 6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e
(git)
Affected: a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < 20a3489b396764cc9376e32a9172bee26a89dc3b (git) Affected: a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < 5bb4228c32261d06e4fbece37ec3828bcc005b6b (git) Affected: a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < c7574740be8ce68a57d0aece24987b9be2114c3c (git) Affected: a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < c40cb5c03e37552d6eff963187109e2c3f78ef6f (git) Affected: a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < 022cac1c693add610ae76ede03adf4d9d5a2cf21 (git) Affected: a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < 7b81425b517accefd46bee854d94954f5c57e019 (git) Affected: a8e3e1a9f02094145580ea7920c6a1d9aabd5539 , < 6d0ce46a93135d96b7fa075a94a88fe0da8e8773 (git) |
guessed | |
| Linux | Linux |
Affected:
4.9
Unaffected: 0 , < 4.9 (semver) Unaffected: 5.4.291 , ≤ 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.79 , ≤ 6.6.* (semver) Unaffected: 6.12.16 , ≤ 6.12.* (semver) Unaffected: 6.13.4 , ≤ 6.13.* (semver) Unaffected: 6.14 , ≤ * (original_commit_for_fix) |
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-21791",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:57:16.236835Z",
"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:26.723Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:59:34.647Z",
"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"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "20a3489b396764cc9376e32a9172bee26a89dc3b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "5bb4228c32261d06e4fbece37ec3828bcc005b6b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c7574740be8ce68a57d0aece24987b9be2114c3c",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c40cb5c03e37552d6eff963187109e2c3f78ef6f",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "022cac1c693add610ae76ede03adf4d9d5a2cf21",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "7b81425b517accefd46bee854d94954f5c57e019",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "6d0ce46a93135d96b7fa075a94a88fe0da8e8773",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.9"
},
{
"lessThan": "4.9",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"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.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.16",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.4",
"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.4.291",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.79",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.16",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.4",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "4.9",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In 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."
}
],
"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 - Both halves of the race are driven from the local system \u2014 a `sendmsg()` on a local socket for the read side, and RTNL link operations (VRF delete/unenslave) for the free side. A remote peer cannot induce the VRF teardown that arms the use-after-free.\nAC:L - The attacker controls both sides of the race and can loop them indefinitely: one thread sends UDP/raw packets out a VRF-enslaved device while another repeatedly unenslaves/deletes the VRF master, with preemption pressure raised at will. `do_vrf_del_slave()` widens the window further by unlinking the adjacency before clearing `IFF_L3MDEV_SLAVE`.\nPR:L - The transmit side needs no privileges at all (ordinary UDP sendmsg), and the VRF create/enslave/delete side needs only CAP_NET_ADMIN within a network namespace, which an unprivileged user obtains via `unshare -Urn`.\nUI:N - The attacker\u0027s own threads perform every step \u2014 socket sends and netlink link operations \u2014 with no victim action required.\nS:U - The use-after-free and its consequences are confined to the kernel\u0027s own security authority; no VM, IOMMU, or other trust boundary is crossed.\nC:H - The freed `netdev_adjacent` sits in a general kmalloc cache and is readily groomed, letting the attacker supply `upper-\u003edev`, after which `master-\u003el3mdev_ops` and `-\u003el3mdev_l3_out` are read from an attacker-chosen address \u2014 an arbitrary kernel read primitive.\nI:H - The same reclaimed object yields an indirect call through an attacker-controlled function pointer with `master` as the first argument, giving control-flow hijack and thus arbitrary kernel-state modification.\nA:H - Even unweaponized, dereferencing a stale adjacency entry and calling through garbage function pointers reliably oopses or panics the kernel, and the attacker can retrigger it at will."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:54:28.163Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e"
},
{
"url": "https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b"
},
{
"url": "https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b"
},
{
"url": "https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c"
},
{
"url": "https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f"
},
{
"url": "https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21"
},
{
"url": "https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019"
},
{
"url": "https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773"
}
],
"title": "vrf: use RCU protection in l3mdev_l3_out()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-21791",
"datePublished": "2025-02-27T02:18:29.014Z",
"dateReserved": "2024-12-29T08:45:45.766Z",
"dateUpdated": "2026-08-05T11:54:28.163Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-21791",
"date": "2026-09-18",
"epss": "0.00263",
"percentile": "0.18522"
},
"microsoft_vex": {
"current_release_date": "2026-02-18T02:19:19.000Z",
"cve": "CVE-2025-21791",
"id": "msrc_CVE-2025-21791",
"initial_release_date": "2025-02-02T00:00:00.000Z",
"product_status:fixed": "5",
"product_status:known_affected": "5",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "vrf: use RCU protection in l3mdev_l3_out()",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-21791.json",
"version": "2"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "20a3489b396764cc9376e32a9172bee26a89dc3b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "5bb4228c32261d06e4fbece37ec3828bcc005b6b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c7574740be8ce68a57d0aece24987b9be2114c3c",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c40cb5c03e37552d6eff963187109e2c3f78ef6f",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "022cac1c693add610ae76ede03adf4d9d5a2cf21",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "7b81425b517accefd46bee854d94954f5c57e019",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "6d0ce46a93135d96b7fa075a94a88fe0da8e8773",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.9"
},
{
"lessThan": "4.9",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"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.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.16",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E1C17A14-0DFF-4500-8A61-0B4CE1F404E5",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B16AADE5-B2FD-4C14-B4E4-85E8EDAFE775",
"versionEndExcluding": "6.6.79",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "13C8DB18-FC60-425F-84E5-3EDDEC61B2FC",
"versionEndExcluding": "6.12.16",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2A2093ED-74A9-43F9-AC72-50030F374EA4",
"versionEndExcluding": "6.13.4",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*",
"matchCriteriaId": "186716B6-2B66-4BD0-852E-D48E71C0C85F",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*",
"matchCriteriaId": "0D3E781C-403A-498F-9DA9-ECEE50F41E75",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In 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."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vrf: usar protecci\u00f3n RCU en l3mdev_l3_out() l3mdev_l3_out() se puede llamar sin que se retenga RCU: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Agregue el par rcu_read_lock() / rcu_read_unlock() para evitar un posible UAF."
}
],
"id": "CVE-2025-21791",
"lastModified": "2026-06-17T08:44:17.250",
"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": "nvd@nist.gov",
"type": "Primary"
},
{
"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-21791",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:57:16.236835Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-02-27T03:15:19.970",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c"
},
{
"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"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-08-19T19:21:52+00:00",
"cve": "CVE-2025-21791",
"id": "CVE-2025-21791",
"initial_release_date": "2025-02-27T00:00:00+00:00",
"product_status:fixed": "917",
"product_status:known_affected": "112",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: vrf: use RCU protection in l3mdev_l3_out()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-21791.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:59:34.647Z",
"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"
},
{
"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-21791",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:57:16.236835Z",
"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-27T17:57:17.808Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "20a3489b396764cc9376e32a9172bee26a89dc3b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "5bb4228c32261d06e4fbece37ec3828bcc005b6b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c7574740be8ce68a57d0aece24987b9be2114c3c",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c40cb5c03e37552d6eff963187109e2c3f78ef6f",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "022cac1c693add610ae76ede03adf4d9d5a2cf21",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "7b81425b517accefd46bee854d94954f5c57e019",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "6d0ce46a93135d96b7fa075a94a88fe0da8e8773",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.9"
},
{
"lessThan": "4.9",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"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.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.16",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.4",
"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.4.291",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.79",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.16",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.4",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "4.9",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In 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."
}
],
"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 - Both halves of the race are driven from the local system \u2014 a `sendmsg()` on a local socket for the read side, and RTNL link operations (VRF delete/unenslave) for the free side. A remote peer cannot induce the VRF teardown that arms the use-after-free.\nAC:L - The attacker controls both sides of the race and can loop them indefinitely: one thread sends UDP/raw packets out a VRF-enslaved device while another repeatedly unenslaves/deletes the VRF master, with preemption pressure raised at will. `do_vrf_del_slave()` widens the window further by unlinking the adjacency before clearing `IFF_L3MDEV_SLAVE`.\nPR:L - The transmit side needs no privileges at all (ordinary UDP sendmsg), and the VRF create/enslave/delete side needs only CAP_NET_ADMIN within a network namespace, which an unprivileged user obtains via `unshare -Urn`.\nUI:N - The attacker\u0027s own threads perform every step \u2014 socket sends and netlink link operations \u2014 with no victim action required.\nS:U - The use-after-free and its consequences are confined to the kernel\u0027s own security authority; no VM, IOMMU, or other trust boundary is crossed.\nC:H - The freed `netdev_adjacent` sits in a general kmalloc cache and is readily groomed, letting the attacker supply `upper-\u003edev`, after which `master-\u003el3mdev_ops` and `-\u003el3mdev_l3_out` are read from an attacker-chosen address \u2014 an arbitrary kernel read primitive.\nI:H - The same reclaimed object yields an indirect call through an attacker-controlled function pointer with `master` as the first argument, giving control-flow hijack and thus arbitrary kernel-state modification.\nA:H - Even unweaponized, dereferencing a stale adjacency entry and calling through garbage function pointers reliably oopses or panics the kernel, and the attacker can retrigger it at will."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:54:28.163Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e"
},
{
"url": "https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b"
},
{
"url": "https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b"
},
{
"url": "https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c"
},
{
"url": "https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f"
},
{
"url": "https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21"
},
{
"url": "https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019"
},
{
"url": "https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773"
}
],
"title": "vrf: use RCU protection in l3mdev_l3_out()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-21791",
"datePublished": "2025-02-27T02:18:29.014Z",
"dateReserved": "2024-12-29T08:45:45.766Z",
"dateUpdated": "2026-08-05T11:54:28.163Z",
"state": "PUBLISHED"
},
"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"
}
]
}
CERTFR-2026-AVI-0168
Vulnerability from certfr_avis - Published: 2026-02-13 - Updated: 2026-02-13
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Certaines d'entre elles permettent à un attaquant de provoquer un déni de service à distance, 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).
None| Vendor | Product | Description | ||
|---|---|---|---|---|
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 9 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian 9 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.8 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.4 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.4 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.4 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.4 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.4 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.6 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian 8 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems 8 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - TUS 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.4 s390x | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.4 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.6 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.4 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - TUS 8.8 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.0 s390x | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 9.4 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 8 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 8 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.4 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 9 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.6 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.8 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Real Time for NFV 8 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.6 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 9.2 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.0 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 8 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.0 ppc64le | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.4 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.0 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian 9 ppc64le | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.4 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.6 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.6 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.8 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems 9 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 8.2 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 9 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Real Time 8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 9 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for IBM z Systems 9 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.4 aarch64 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 9 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 9 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.4 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.4 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.4 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.4 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.4 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.6 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 8 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 8 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - TUS 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.4 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.4 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.6 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.4 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - TUS 8.8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.0 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.4 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 8 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.4 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 9 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.6 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time for NFV 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.6 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.2 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.0 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 8 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.0 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.4 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.0 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 9 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.4 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.6 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.6 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.8 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 9 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 8.2 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 9 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 9 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems 9 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.4 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
}
],
"affected_systems_content": null,
"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-21786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21786"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2023-53833",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53833"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2022-49503",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49503"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2025-21647",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21647"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2022-50341",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50341"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2022-50673",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50673"
},
{
"name": "CVE-2025-38024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38024"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2023-53673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53673"
},
{
"name": "CVE-2025-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38568"
},
{
"name": "CVE-2023-53539",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53539"
},
{
"name": "CVE-2025-40158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40158"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2023-53751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53751"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2022-50865",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50865"
},
{
"name": "CVE-2025-40170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40170"
},
{
"name": "CVE-2024-54456",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54456"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2025-38730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38730"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2023-53581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53581"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2023-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53192"
}
],
"initial_release_date": "2026-02-13T00:00:00",
"last_revision_date": "2026-02-13T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0168",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-02-13T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de Red Hat. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer un d\u00e9ni de service \u00e0 distance, 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 de Red Hat",
"vendor_advisories": [
{
"published_at": "2026-02-11",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2490",
"url": "https://access.redhat.com/errata/RHSA-2026:2490"
},
{
"published_at": "2026-02-09",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2264",
"url": "https://access.redhat.com/errata/RHSA-2026:2264"
},
{
"published_at": "2026-02-12",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2664",
"url": "https://access.redhat.com/errata/RHSA-2026:2664"
},
{
"published_at": "2026-02-09",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2212",
"url": "https://access.redhat.com/errata/RHSA-2026:2212"
},
{
"published_at": "2026-02-09",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2352",
"url": "https://access.redhat.com/errata/RHSA-2026:2352"
},
{
"published_at": "2026-02-10",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2378",
"url": "https://access.redhat.com/errata/RHSA-2026:2378"
},
{
"published_at": "2026-02-11",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2573",
"url": "https://access.redhat.com/errata/RHSA-2026:2573"
},
{
"published_at": "2026-02-11",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2577",
"url": "https://access.redhat.com/errata/RHSA-2026:2577"
},
{
"published_at": "2026-02-12",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2594",
"url": "https://access.redhat.com/errata/RHSA-2026:2594"
},
{
"published_at": "2026-02-11",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2535",
"url": "https://access.redhat.com/errata/RHSA-2026:2535"
},
{
"published_at": "2026-02-11",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2560",
"url": "https://access.redhat.com/errata/RHSA-2026:2560"
},
{
"published_at": "2026-02-11",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:2583",
"url": "https://access.redhat.com/errata/RHSA-2026:2583"
}
]
}
FKIE_CVE-2025-21791
Vulnerability from fkie_nvd - Published: 2025-02-27 03:15 - Updated: 2026-06-17 08:447.8 (High) - CVSS:3.1/
| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c | 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 |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.14 | |
| linux | linux_kernel | 6.14 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "20a3489b396764cc9376e32a9172bee26a89dc3b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "5bb4228c32261d06e4fbece37ec3828bcc005b6b",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c7574740be8ce68a57d0aece24987b9be2114c3c",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "c40cb5c03e37552d6eff963187109e2c3f78ef6f",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "022cac1c693add610ae76ede03adf4d9d5a2cf21",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "7b81425b517accefd46bee854d94954f5c57e019",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
},
{
"lessThan": "6d0ce46a93135d96b7fa075a94a88fe0da8e8773",
"status": "affected",
"version": "a8e3e1a9f02094145580ea7920c6a1d9aabd5539",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/l3mdev.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.9"
},
{
"lessThan": "4.9",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"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.79",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.16",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E1C17A14-0DFF-4500-8A61-0B4CE1F404E5",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "4.9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B16AADE5-B2FD-4C14-B4E4-85E8EDAFE775",
"versionEndExcluding": "6.6.79",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "13C8DB18-FC60-425F-84E5-3EDDEC61B2FC",
"versionEndExcluding": "6.12.16",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2A2093ED-74A9-43F9-AC72-50030F374EA4",
"versionEndExcluding": "6.13.4",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*",
"matchCriteriaId": "186716B6-2B66-4BD0-852E-D48E71C0C85F",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*",
"matchCriteriaId": "0D3E781C-403A-498F-9DA9-ECEE50F41E75",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In 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."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vrf: usar protecci\u00f3n RCU en l3mdev_l3_out() l3mdev_l3_out() se puede llamar sin que se retenga RCU: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Agregue el par rcu_read_lock() / rcu_read_unlock() para evitar un posible UAF."
}
],
"id": "CVE-2025-21791",
"lastModified": "2026-06-17T08:44:17.250",
"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": "nvd@nist.gov",
"type": "Primary"
},
{
"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-21791",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:57:16.236835Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-02-27T03:15:19.970",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c"
},
{
"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"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-VR2W-W74G-R822
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-11-03 21:33In 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.
{
"affected": [],
"aliases": [
"CVE-2025-21791"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T03:15:19Z",
"severity": "HIGH"
},
"details": "In 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.",
"id": "GHSA-vr2w-w74g-r822",
"modified": "2025-11-03T21:33:01Z",
"published": "2025-02-27T03:34:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c"
},
{
"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"
}
]
}
MSRC_CVE-2025-21791
Vulnerability from csaf_microsoft - Published: 2025-02-02 00:00 - Updated: 2026-02-18 02:19OESA-2025-1317 (CVE-2021-47634)
Vulnerability from osv_openeuler – Published: 2025-03-21 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl
Hulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi]
Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi]
Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================
The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can be concurrent.
ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach. ubi_detach is bug-free because it uses reference counting to prevent concurrency. However, uif_init and uif_close in ubi_attach may race with ubi_cdev_ioctl.
uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _____|___|_______ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_del
And uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _____|___|_______ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double free
The cause of this problem is that commit 714fb87e8bc0 make device "available" before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix the race condition between ubi device creation and udev by removing ubi_get_device in vol_attribute_show and dev_attribute_show.This avoids accessing uninitialized ubi_devices[ubi_num].
ubi_get_device is used to prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will not be deleted before all reference counting are released. The key process is shown in the following stack.
device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain(CVE-2021-47634)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix use-after-free in jffs2_clear_xattr_subsystem
When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super().
Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719
Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]
Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...]
The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ==================================================================
The triggering of the BUG is shown in the following stack:
jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again
An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem.(CVE-2021-47656)
In the Linux kernel, the following vulnerability has been resolved:
mm: fix unexpected zeroed page mapping with zram swap
Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly.
CPU A CPU B
do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the zero data to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data
The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data.
CPU A CPU B
do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B
The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly.(CVE-2022-49052)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix a race in rxrpc_exit_net()
Current code can lead to the following race:
CPU0 CPU1
rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live)
rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer);
timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);
cancel_work_sync(&rxnet->peer_keepalive_work);
rxrpc_exit_net() exits while peer_keepalive_timer is still armed, leading to use-after-free.
syzbot report was:
ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0 WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0 R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 </TASK>(CVE-2022-49087)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()
[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e(CVE-2022-49155)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA: firewire-lib: Add support for deferred transaction") while 'deferrable' flag can be uninitialized for non-control/notify AV/C transactions. UBSAN reports it:
kernel: ================================================================================ kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9 kernel: load of value 158 is not a valid value for type '_Bool' kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019 kernel: Call Trace: kernel: <IRQ> kernel: show_stack+0x52/0x58 kernel: dump_stack_lvl+0x4a/0x5f kernel: dump_stack+0x10/0x12 kernel: ubsan_epilogue+0x9/0x45 kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49 kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib] kernel: fcp_response+0x28/0x30 [snd_firewire_lib] kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core] kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core] kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci] kernel: tasklet_action_common.constprop.0+0xea/0xf0 kernel: tasklet_action+0x22/0x30 kernel: __do_softirq+0xd9/0x2e3 kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0 kernel: do_softirq+0x75/0xa0 kernel: </IRQ> kernel: <TASK> kernel: __local_bh_enable_ip+0x50/0x60 kernel: irq_forced_thread_fn+0x7e/0x90 kernel: irq_thread+0xba/0x190 kernel: ? irq_thread_fn+0x60/0x60 kernel: kthread+0x11e/0x140 kernel: ? irq_thread_check_affinity+0xf0/0xf0 kernel: ? set_kthread_struct+0x50/0x50 kernel: ret_from_fork+0x22/0x30 kernel: </TASK> kernel: ================================================================================
This commit fixes the bug. The bug has no disadvantage for the non- control/notify AV/C transactions since the flag has an effect for AV/C response with INTERIM (0x0f) status which is not used for the transactions in AV/C general specification.(CVE-2022-49248)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_scan_medium
If an error is returned in jffs2_scan_eraseblock() and some memory has been added to the jffs2_summary *s, we can observe the following kmemleak report:
unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ backtrace: [<ffffffffae93a3a3>] __kmalloc+0x613/0x910 [<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+0x5c/0xa0 [<ffffffffb0f3afa8>] jffs2_scan_medium.cold+0x36e5/0x4794 [<ffffffffb0f3dbe1>] jffs2_do_mount_fs.cold+0xa7/0x2267 [<ffffffffaf40acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffaf40c00a>] jffs2_fill_super+0x2ea/0x4c0 [<ffffffffb0315d64>] mtd_get_sb+0x254/0x400 [<ffffffffb0315f5f>] mtd_get_sb_by_nr+0x4f/0xd0 [<ffffffffb0316478>] get_tree_mtd+0x498/0x840 [<ffffffffaf40bd15>] jffs2_get_tree+0x25/0x30 [<ffffffffae9f358d>] vfs_get_tree+0x8d/0x2e0 [<ffffffffaea7a98f>] path_mount+0x50f/0x1e50 [<ffffffffaea7c3d7>] do_mount+0x107/0x130 [<ffffffffaea7c5c5>] __se_sys_mount+0x1c5/0x2f0 [<ffffffffaea7c917>] __x64_sys_mount+0xc7/0x160 [<ffffffffb10142f5>] do_syscall_64+0x45/0x70 unreferenced object 0xffff888114b54840 (size 32): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423b04>] jffs2_sum_add_inode_mem+0x54/0x90 [<ffffffffb0f3bd44>] jffs2_scan_medium.cold+0x4481/0x4794 [...] unreferenced object 0xffff888114b57280 (size 32): comm "mount", pid 692, jiffies 4294838393 (age 34.357s) hex dump (first 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423c34>] jffs2_sum_add_xattr_mem+0x54/0x90 [<ffffffffb0f3a24f>] jffs2_scan_medium.cold+0x298c/0x4794 [...] unreferenced object 0xffff8881116cd510 (size 16): comm "mount", pid 692, jiffies 4294838395 (age 34.355s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423cc4>] jffs2_sum_add_xref_mem+0x54/0x90 [<ffffffffb0f3b2e3>] jffs2_scan_medium.cold+0x3a20/0x4794 [...]
Therefore, we should call jffs2_sum_reset_collected(s) on exit to release the memory added in s. In addition, a new tag "out_buf" is added to prevent the NULL pointer reference caused by s being NULL. (thanks to Zhang Yi for this analysis)(CVE-2022-49276)
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_mount_fs
If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error, we can observe the following kmemleak report:
unreferenced object 0xffff88811b25a640 (size 64): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...] unreferenced object 0xffff88812c760000 (size 65536): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffffa493a449>] __kmalloc+0x6b9/0x910 [<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...]
This is because the resources allocated in jffs2_sum_init() are not released. Call jffs2_sum_exit() to release these resources to solve the problem.(CVE-2022-49277)
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()
There is a deadlock in rtllib_beacons_stop(), which is shown below:
(Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ...
We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.(CVE-2022-49315)
In the Linux kernel, the following vulnerability has been resolved:
mips: cpc: Fix refcount leak in mips_cpc_default_phys_base
Add the missing of_node_put() to release the refcount incremented by of_find_compatible_node().(CVE-2022-49324)
In the Linux kernel, the following vulnerability has been resolved:
nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.(CVE-2022-49331)
In the Linux kernel, the following vulnerability has been resolved:
rtc: mt6397: check return value after calling platform_get_resource()
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.(CVE-2022-49375)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix race condition between ext4_write and ext4_convert_inline_data
Hulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ==================================================================
Above issue may happen as follows: cpu1 cpu2 ____|___ dopwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON
The lock held by ext4_convert_inline_data is xattr_sem, but the lock held by generic_perform_write is i_rwsem. Therefore, the two locks can be concurrent.
To solve above issue, we add inode_lock() for ext4_convert_inline_data(). At the same time, move ext4_convert_inline_data() in front of ext4_punch_hole(), remove similar handling from ext4_punch_hole().(CVE-2022-49414)
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected
There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned.
To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error.
Patchwork: https://patchwork.freedesktop.org/patch/485181/(CVE-2022-49488)
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume
BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3
Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c
Patchwork: https://patchwork.freedesktop.org/patch/483255/ DB: fixed Fixes tag
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:
ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe
Call of_node_put(platform_node) to avoid refcount leak in the error path.(CVE-2022-49514)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: avoid null dereference in deinit
If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore.
Avoid this null pointer derefence by skipping the call when necessary.(CVE-2022-49527)
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218(CVE-2022-49532)
In the Linux kernel, the following vulnerability has been resolved:
ipw2x00: Fix potential NULL dereference in libipw_xmit()
crypt and crypt->ops could be null, so we need to checking null before dereference(CVE-2022-49544)
In the Linux kernel, the following vulnerability has been resolved:
be2net: Fix buffer overflow in be_get_module_eeprom
be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once.(CVE-2022-49581)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: ralink: Check for null return of devm_kcalloc
Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.".(CVE-2022-49608)
In the Linux kernel, the following vulnerability has been resolved:
xtensa: Fix refcount leak bug in time.c
In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.(CVE-2022-49682)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix call trace in setup_tx_descriptors
After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors.
Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash.
Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test()(CVE-2022-49725)
In the Linux kernel, the following vulnerability has been resolved:
nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred
Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well.
Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them.
So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak.
Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.(CVE-2022-49729)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
A NULL sock pointer is passed into l2cap_sock_alloc() when it is called from l2cap_sock_new_connection_cb() and the error handling paths should also be aware of it.
Seemingly a more elegant solution would be to swap bt_sock_alloc() and l2cap_chan_create() calls since they are not interdependent to that moment but then l2cap_chan_create() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls.
Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.(CVE-2024-58009)
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)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2503.4.0.0320.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2503.4.0.0320.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2503.4.0.0320.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl\n\nHulk Robot reported a KASAN report about use-after-free:\n ==================================================================\n BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160\n Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385\n [...]\n Call Trace:\n klist_dec_and_del+0xa7/0x4a0\n klist_put+0xc7/0x1a0\n device_del+0x4d4/0xed0\n cdev_device_del+0x1a/0x80\n ubi_attach_mtd_dev+0x2951/0x34b0 [ubi]\n ctrl_cdev_ioctl+0x286/0x2f0 [ubi]\n\n Allocated by task 1414:\n device_add+0x60a/0x18b0\n cdev_device_add+0x103/0x170\n ubi_create_volume+0x1118/0x1a10 [ubi]\n ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi]\n\n Freed by task 1385:\n cdev_device_del+0x1a/0x80\n ubi_remove_volume+0x438/0x6c0 [ubi]\n ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi]\n [...]\n ==================================================================\n\nThe lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held\nby ubi_cdev_ioctl is ubi-\u0026gt;device_mutex. Therefore, the two locks can be\nconcurrent.\n\nctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.\nubi_detach is bug-free because it uses reference counting to prevent\nconcurrency. However, uif_init and uif_close in ubi_attach may race with\nubi_cdev_ioctl.\n\nuif_init will race with ubi_cdev_ioctl as in the following stack.\n cpu1 cpu2 cpu3\n_______________________|________________________|______________________\nctrl_cdev_ioctl\n ubi_attach_mtd_dev\n uif_init\n ubi_cdev_ioctl\n ubi_create_volume\n cdev_device_add\n ubi_add_volume\n // sysfs exist\n kill_volumes\n ubi_cdev_ioctl\n ubi_remove_volume\n cdev_device_del\n // first free\n ubi_free_volume\n cdev_del\n // double free\n cdev_device_del\n\nAnd uif_close will race with ubi_cdev_ioctl as in the following stack.\n cpu1 cpu2 cpu3\n_______________________|________________________|______________________\nctrl_cdev_ioctl\n ubi_attach_mtd_dev\n uif_init\n ubi_cdev_ioctl\n ubi_create_volume\n cdev_device_add\n ubi_debugfs_init_dev\n //error goto out_uif;\n uif_close\n kill_volumes\n ubi_cdev_ioctl\n ubi_remove_volume\n cdev_device_del\n // first free\n ubi_free_volume\n // double free\n\nThe cause of this problem is that commit 714fb87e8bc0 make device\n\u0026quot;available\u0026quot; before it becomes accessible via sysfs. Therefore, we\nroll back the modification. We will fix the race condition between\nubi device creation and udev by removing ubi_get_device in\nvol_attribute_show and dev_attribute_show.This avoids accessing\nuninitialized ubi_devices[ubi_num].\n\nubi_get_device is used to prevent devices from being deleted during\nsysfs execution. However, now kernfs ensures that devices will not\nbe deleted before all reference counting are released.\nThe key process is shown in the following stack.\n\ndevice_del\n device_remove_attrs\n device_remove_groups\n sysfs_remove_groups\n sysfs_remove_group\n remove_files\n kernfs_remove_by_name\n kernfs_remove_by_name_ns\n __kernfs_remove\n kernfs_drain(CVE-2021-47634)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix use-after-free in jffs2_clear_xattr_subsystem\n\nWhen we mount a jffs2 image, assume that the first few blocks of\nthe image are normal and contain at least one xattr-related inode,\nbut the next block is abnormal. As a result, an error is returned\nin jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then\ncalled in jffs2_build_filesystem() and then again in\njffs2_do_fill_super().\n\nFinally we can observe the following report:\n ==================================================================\n BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac\n Read of size 8 at addr ffff8881243384e0 by task mount/719\n\n Call Trace:\n dump_stack+0x115/0x16b\n jffs2_clear_xattr_subsystem+0x95/0x6ac\n jffs2_do_fill_super+0x84f/0xc30\n jffs2_fill_super+0x2ea/0x4c0\n mtd_get_sb+0x254/0x400\n mtd_get_sb_by_nr+0x4f/0xd0\n get_tree_mtd+0x498/0x840\n jffs2_get_tree+0x25/0x30\n vfs_get_tree+0x8d/0x2e0\n path_mount+0x50f/0x1e50\n do_mount+0x107/0x130\n __se_sys_mount+0x1c5/0x2f0\n __x64_sys_mount+0xc7/0x160\n do_syscall_64+0x45/0x70\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\n Allocated by task 719:\n kasan_save_stack+0x23/0x60\n __kasan_kmalloc.constprop.0+0x10b/0x120\n kasan_slab_alloc+0x12/0x20\n kmem_cache_alloc+0x1c0/0x870\n jffs2_alloc_xattr_ref+0x2f/0xa0\n jffs2_scan_medium.cold+0x3713/0x4794\n jffs2_do_mount_fs.cold+0xa7/0x2253\n jffs2_do_fill_super+0x383/0xc30\n jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n Freed by task 719:\n kmem_cache_free+0xcc/0x7b0\n jffs2_free_xattr_ref+0x78/0x98\n jffs2_clear_xattr_subsystem+0xa1/0x6ac\n jffs2_do_mount_fs.cold+0x5e6/0x2253\n jffs2_do_fill_super+0x383/0xc30\n jffs2_fill_super+0x2ea/0x4c0\n [...]\n\n The buggy address belongs to the object at ffff8881243384b8\n which belongs to the cache jffs2_xattr_ref of size 48\n The buggy address is located 40 bytes inside of\n 48-byte region [ffff8881243384b8, ffff8881243384e8)\n [...]\n ==================================================================\n\nThe triggering of the BUG is shown in the following stack:\n-----------------------------------------------------------\njffs2_fill_super\n jffs2_do_fill_super\n jffs2_do_mount_fs\n jffs2_build_filesystem\n jffs2_scan_medium\n jffs2_scan_eraseblock \u0026lt;--- ERROR\n jffs2_clear_xattr_subsystem \u0026lt;--- free\n jffs2_clear_xattr_subsystem \u0026lt;--- free again\n-----------------------------------------------------------\n\nAn error is returned in jffs2_do_mount_fs(). If the error is returned\nby jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to\nbe executed. If the error is returned by jffs2_build_filesystem(), the\njffs2_clear_xattr_subsystem() also does not need to be executed again.\nSo move jffs2_clear_xattr_subsystem() from \u0026apos;out_inohash\u0026apos; to \u0026apos;out_root\u0026apos;\nto fix this UAF problem.(CVE-2021-47656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix unexpected zeroed page mapping with zram swap\n\nTwo processes under CLONE_VM cloning, user process can be corrupted by\nseeing zeroed page unexpectedly.\n\n CPU A CPU B\n\n do_swap_page do_swap_page\n SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path\n swap_readpage valid data\n swap_slot_free_notify\n delete zram entry\n swap_readpage zeroed(invalid) data\n pte_lock\n map the *zero data* to userspace\n pte_unlock\n pte_lock\n if (!pte_same)\n goto out_nomap;\n pte_unlock\n return and next refault will\n read zeroed data\n\nThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn\u0026apos;t\nincrease the refcount of swap slot at copy_mm so it couldn\u0026apos;t catch up\nwhether it\u0026apos;s safe or not to discard data from backing device. In the\ncase, only the lock it could rely on to synchronize swap slot freeing is\npage table lock. Thus, this patch gets rid of the swap_slot_free_notify\nfunction. With this patch, CPU A will see correct data.\n\n CPU A CPU B\n\n do_swap_page do_swap_page\n SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path\n swap_readpage original data\n pte_lock\n map the original data\n swap_free\n swap_range_free\n bd_disk-\u0026gt;fops-\u0026gt;swap_slot_free_notify\n swap_readpage read zeroed data\n pte_unlock\n pte_lock\n if (!pte_same)\n goto out_nomap;\n pte_unlock\n return\n on next refault will see mapped data by CPU B\n\nThe concern of the patch would increase memory consumption since it\ncould keep wasted memory with compressed form in zram as well as\nuncompressed form in address space. However, most of cases of zram uses\nno readahead and do_swap_page is followed by swap_free so it will free\nthe compressed form from in zram quickly.(CVE-2022-49052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: fix a race in rxrpc_exit_net()\n\nCurrent code can lead to the following race:\n\nCPU0 CPU1\n\nrxrpc_exit_net()\n rxrpc_peer_keepalive_worker()\n if (rxnet-\u0026gt;live)\n\n rxnet-\u0026gt;live = false;\n del_timer_sync(\u0026amp;rxnet-\u0026gt;peer_keepalive_timer);\n\n timer_reduce(\u0026amp;rxnet-\u0026gt;peer_keepalive_timer, jiffies + delay);\n\n cancel_work_sync(\u0026amp;rxnet-\u0026gt;peer_keepalive_work);\n\nrxrpc_exit_net() exits while peer_keepalive_timer is still armed,\nleading to use-after-free.\n\nsyzbot report was:\n\nODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0\nWARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nModules linked in:\nCPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nCode: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 \u0026lt;0f\u0026gt; 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3\nRSP: 0018:ffffc9000353fb00 EFLAGS: 00010082\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000\nRDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0\nR13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]\n debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023\n kfree+0xd6/0x310 mm/slab.c:3809\n ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176\n ops_free_list net/core/net_namespace.c:174 [inline]\n cleanup_net+0x591/0xb00 net/core/net_namespace.c:598\n process_one_work+0x996/0x1610 kernel/workqueue.c:2289\n worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n kthread+0x2e9/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298\n \u0026lt;/TASK\u0026gt;(CVE-2022-49087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair()\n\n[ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020\n[ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]\n[ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1\n[ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018\n[ 12.356356] Call Trace:\n[ 12.358821] dump_stack_lvl+0x34/0x44\n[ 12.362514] check_preemption_disabled+0xd9/0xe0\n[ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx]\n[ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx]\n[ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40\n[ 12.384284] local_pci_probe+0x42/0x80\n[ 12.390162] ? pci_match_device+0xd7/0x110\n[ 12.396366] pci_device_probe+0xfd/0x1b0\n[ 12.402372] really_probe+0x1e7/0x3e0\n[ 12.408114] __driver_probe_device+0xfe/0x180\n[ 12.414544] driver_probe_device+0x1e/0x90\n[ 12.420685] __driver_attach+0xc0/0x1c0\n[ 12.426536] ? __device_attach_driver+0xe0/0xe0\n[ 12.433061] ? __device_attach_driver+0xe0/0xe0\n[ 12.439538] bus_for_each_dev+0x78/0xc0\n[ 12.445294] bus_add_driver+0x12b/0x1e0\n[ 12.451021] driver_register+0x8f/0xe0\n[ 12.456631] ? 0xffffffffc07bc000\n[ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx]\n[ 12.468776] do_one_initcall+0x44/0x200\n[ 12.474401] ? load_module+0xad3/0xba0\n[ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410\n[ 12.486268] do_init_module+0x5c/0x280\n[ 12.491730] __do_sys_init_module+0x12e/0x1b0\n[ 12.497785] do_syscall_64+0x3b/0x90\n[ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 12.509764] RIP: 0033:0x7f554f73ab2e(CVE-2022-49155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction\n\nAV/C deferred transaction was supported at a commit 00a7bb81c20f (\u0026quot;ALSA:\nfirewire-lib: Add support for deferred transaction\u0026quot;) while \u0026apos;deferrable\u0026apos;\nflag can be uninitialized for non-control/notify AV/C transactions.\nUBSAN reports it:\n\nkernel: ================================================================================\nkernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9\nkernel: load of value 158 is not a valid value for type \u0026apos;_Bool\u0026apos;\nkernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu\nkernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019\nkernel: Call Trace:\nkernel: \u0026lt;IRQ\u0026gt;\nkernel: show_stack+0x52/0x58\nkernel: dump_stack_lvl+0x4a/0x5f\nkernel: dump_stack+0x10/0x12\nkernel: ubsan_epilogue+0x9/0x45\nkernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49\nkernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]\nkernel: fcp_response+0x28/0x30 [snd_firewire_lib]\nkernel: fw_core_handle_request+0x230/0x3d0 [firewire_core]\nkernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci]\nkernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]\nkernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core]\nkernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]\nkernel: tasklet_action_common.constprop.0+0xea/0xf0\nkernel: tasklet_action+0x22/0x30\nkernel: __do_softirq+0xd9/0x2e3\nkernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0\nkernel: do_softirq+0x75/0xa0\nkernel: \u0026lt;/IRQ\u0026gt;\nkernel: \u0026lt;TASK\u0026gt;\nkernel: __local_bh_enable_ip+0x50/0x60\nkernel: irq_forced_thread_fn+0x7e/0x90\nkernel: irq_thread+0xba/0x190\nkernel: ? irq_thread_fn+0x60/0x60\nkernel: kthread+0x11e/0x140\nkernel: ? irq_thread_check_affinity+0xf0/0xf0\nkernel: ? set_kthread_struct+0x50/0x50\nkernel: ret_from_fork+0x22/0x30\nkernel: \u0026lt;/TASK\u0026gt;\nkernel: ================================================================================\n\nThis commit fixes the bug. The bug has no disadvantage for the non-\ncontrol/notify AV/C transactions since the flag has an effect for AV/C\nresponse with INTERIM (0x0f) status which is not used for the transactions\nin AV/C general specification.(CVE-2022-49248)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_scan_medium\n\nIf an error is returned in jffs2_scan_eraseblock() and some memory\nhas been added to the jffs2_summary *s, we can observe the following\nkmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff88812b889c40 (size 64):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838325 (age 34.288s)\n hex dump (first 32 bytes):\n 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P.\n 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................\n backtrace:\n [\u0026lt;ffffffffae93a3a3\u0026gt;] __kmalloc+0x613/0x910\n [\u0026lt;ffffffffaf423b9c\u0026gt;] jffs2_sum_add_dirent_mem+0x5c/0xa0\n [\u0026lt;ffffffffb0f3afa8\u0026gt;] jffs2_scan_medium.cold+0x36e5/0x4794\n [\u0026lt;ffffffffb0f3dbe1\u0026gt;] jffs2_do_mount_fs.cold+0xa7/0x2267\n [\u0026lt;ffffffffaf40acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n [\u0026lt;ffffffffaf40c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n [\u0026lt;ffffffffb0315d64\u0026gt;] mtd_get_sb+0x254/0x400\n [\u0026lt;ffffffffb0315f5f\u0026gt;] mtd_get_sb_by_nr+0x4f/0xd0\n [\u0026lt;ffffffffb0316478\u0026gt;] get_tree_mtd+0x498/0x840\n [\u0026lt;ffffffffaf40bd15\u0026gt;] jffs2_get_tree+0x25/0x30\n [\u0026lt;ffffffffae9f358d\u0026gt;] vfs_get_tree+0x8d/0x2e0\n [\u0026lt;ffffffffaea7a98f\u0026gt;] path_mount+0x50f/0x1e50\n [\u0026lt;ffffffffaea7c3d7\u0026gt;] do_mount+0x107/0x130\n [\u0026lt;ffffffffaea7c5c5\u0026gt;] __se_sys_mount+0x1c5/0x2f0\n [\u0026lt;ffffffffaea7c917\u0026gt;] __x64_sys_mount+0xc7/0x160\n [\u0026lt;ffffffffb10142f5\u0026gt;] do_syscall_64+0x45/0x70\nunreferenced object 0xffff888114b54840 (size 32):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838325 (age 34.288s)\n hex dump (first 32 bytes):\n c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u..............\n 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk.\n backtrace:\n [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffaf423b04\u0026gt;] jffs2_sum_add_inode_mem+0x54/0x90\n [\u0026lt;ffffffffb0f3bd44\u0026gt;] jffs2_scan_medium.cold+0x4481/0x4794\n [...]\nunreferenced object 0xffff888114b57280 (size 32):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838393 (age 34.357s)\n hex dump (first 32 bytes):\n 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l.............\n 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk.\n backtrace:\n [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffaf423c34\u0026gt;] jffs2_sum_add_xattr_mem+0x54/0x90\n [\u0026lt;ffffffffb0f3a24f\u0026gt;] jffs2_scan_medium.cold+0x298c/0x4794\n [...]\nunreferenced object 0xffff8881116cd510 (size 16):\n comm \u0026quot;mount\u0026quot;, pid 692, jiffies 4294838395 (age 34.355s)\n hex dump (first 16 bytes):\n 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k.\n backtrace:\n [\u0026lt;ffffffffae93be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffaf423cc4\u0026gt;] jffs2_sum_add_xref_mem+0x54/0x90\n [\u0026lt;ffffffffb0f3b2e3\u0026gt;] jffs2_scan_medium.cold+0x3a20/0x4794\n [...]\n--------------------------------------------\n\nTherefore, we should call jffs2_sum_reset_collected(s) on exit to\nrelease the memory added in s. In addition, a new tag \u0026quot;out_buf\u0026quot; is\nadded to prevent the NULL pointer reference caused by s being NULL.\n(thanks to Zhang Yi for this analysis)(CVE-2022-49276)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njffs2: fix memory leak in jffs2_do_mount_fs\n\nIf jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,\nwe can observe the following kmemleak report:\n\n--------------------------------------------\nunreferenced object 0xffff88811b25a640 (size 64):\n comm \u0026quot;mount\u0026quot;, pid 691, jiffies 4294957728 (age 71.952s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;ffffffffa493be24\u0026gt;] kmem_cache_alloc_trace+0x584/0x880\n [\u0026lt;ffffffffa5423a06\u0026gt;] jffs2_sum_init+0x86/0x130\n [\u0026lt;ffffffffa5400e58\u0026gt;] jffs2_do_mount_fs+0x798/0xac0\n [\u0026lt;ffffffffa540acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n [\u0026lt;ffffffffa540c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n [...]\nunreferenced object 0xffff88812c760000 (size 65536):\n comm \u0026quot;mount\u0026quot;, pid 691, jiffies 4294957728 (age 71.952s)\n hex dump (first 32 bytes):\n bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................\n bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................\n backtrace:\n [\u0026lt;ffffffffa493a449\u0026gt;] __kmalloc+0x6b9/0x910\n [\u0026lt;ffffffffa5423a57\u0026gt;] jffs2_sum_init+0xd7/0x130\n [\u0026lt;ffffffffa5400e58\u0026gt;] jffs2_do_mount_fs+0x798/0xac0\n [\u0026lt;ffffffffa540acf3\u0026gt;] jffs2_do_fill_super+0x383/0xc30\n [\u0026lt;ffffffffa540c00a\u0026gt;] jffs2_fill_super+0x2ea/0x4c0\n [...]\n--------------------------------------------\n\nThis is because the resources allocated in jffs2_sum_init() are not\nreleased. Call jffs2_sum_exit() to release these resources to solve\nthe problem.(CVE-2022-49277)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()\n\nThere is a deadlock in rtllib_beacons_stop(), which is shown\nbelow:\n\n (Thread 1) | (Thread 2)\n | rtllib_send_beacon()\nrtllib_beacons_stop() | mod_timer()\n spin_lock_irqsave() //(1) | (wait a time)\n ... | rtllib_send_beacon_cb()\n del_timer_sync() | spin_lock_irqsave() //(2)\n (wait timer to stop) | ...\n\nWe hold ieee-\u0026gt;beacon_lock in position (1) of thread 1 and\nuse del_timer_sync() to wait timer to stop, but timer handler\nalso need ieee-\u0026gt;beacon_lock in position (2) of thread 2.\nAs a result, rtllib_beacons_stop() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irqsave(), which could let timer handler to obtain\nthe needed lock.(CVE-2022-49315)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmips: cpc: Fix refcount leak in mips_cpc_default_phys_base\n\nAdd the missing of_node_put() to release the refcount incremented\nby of_find_compatible_node().(CVE-2022-49324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling\n\nError paths do not free previously allocated memory. Add devm_kfree() to\nthose failure paths.(CVE-2022-49331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: mt6397: check return value after calling platform_get_resource()\n\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2022-49375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix race condition between ext4_write and ext4_convert_inline_data\n\nHulk Robot reported a BUG_ON:\n ==================================================================\n EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0,\n block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters\n kernel BUG at fs/ext4/ext4_jbd2.c:53!\n invalid opcode: 0000 [#1] SMP KASAN PTI\n CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1\n RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline]\n RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116\n [...]\n Call Trace:\n ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795\n generic_perform_write+0x279/0x3c0 mm/filemap.c:3344\n ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270\n ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520\n do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732\n do_iter_write+0x107/0x430 fs/read_write.c:861\n vfs_writev fs/read_write.c:934 [inline]\n do_pwritev+0x1e5/0x380 fs/read_write.c:1031\n [...]\n ==================================================================\n\nAbove issue may happen as follows:\n cpu1 cpu2\n__________________________|__________________________\ndo_pwritev\n vfs_writev\n do_iter_write\n ext4_file_write_iter\n ext4_buffered_write_iter\n generic_perform_write\n ext4_da_write_begin\n vfs_fallocate\n ext4_fallocate\n ext4_convert_inline_data\n ext4_convert_inline_data_nolock\n ext4_destroy_inline_data_nolock\n clear EXT4_STATE_MAY_INLINE_DATA\n ext4_map_blocks\n ext4_ext_map_blocks\n ext4_mb_new_blocks\n ext4_mb_regular_allocator\n ext4_mb_good_group_nolock\n ext4_mb_init_group\n ext4_mb_init_cache\n ext4_mb_generate_buddy --\u0026gt; error\n ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)\n ext4_restore_inline_data\n set EXT4_STATE_MAY_INLINE_DATA\n ext4_block_write_begin\n ext4_da_write_end\n ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)\n ext4_write_inline_data_end\n handle=NULL\n ext4_journal_stop(handle)\n __ext4_journal_stop\n ext4_put_nojournal(handle)\n ref_cnt = (unsigned long)handle\n BUG_ON(ref_cnt == 0) ---\u0026gt; BUG_ON\n\nThe lock held by ext4_convert_inline_data is xattr_sem, but the lock\nheld by generic_perform_write is i_rwsem. Therefore, the two locks can\nbe concurrent.\n\nTo solve above issue, we add inode_lock() for ext4_convert_inline_data().\nAt the same time, move ext4_convert_inline_data() in front of\next4_punch_hole(), remove similar handling from ext4_punch_hole().(CVE-2022-49414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected\n\nThere is a possibility for mdp5_get_global_state to return\n-EDEADLK when acquiring the modeset lock, but currently global_state in\nmdp5_mixer_release doesn\u0026apos;t check for if an error is returned.\n\nTo avoid a NULL dereference error, let\u0026apos;s have mdp5_mixer_release\ncheck if an error is returned and propagate that error.\n\nPatchwork: https://patchwork.freedesktop.org/patch/485181/(CVE-2022-49488)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume\n\nBUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3\n\nCall trace:\n dpu_vbif_init_memtypes+0x40/0xb8\n dpu_runtime_resume+0xcc/0x1c0\n pm_generic_runtime_resume+0x30/0x44\n __genpd_runtime_resume+0x68/0x7c\n genpd_runtime_resume+0x134/0x258\n __rpm_callback+0x98/0x138\n rpm_callback+0x30/0x88\n rpm_resume+0x36c/0x49c\n __pm_runtime_resume+0x80/0xb0\n dpu_core_irq_uninstall+0x30/0xb0\n dpu_irq_uninstall+0x18/0x24\n msm_drm_uninit+0xd8/0x16c\n\nPatchwork: https://patchwork.freedesktop.org/patch/483255/\n[DB: fixed Fixes tag](CVE-2022-49489)\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\nASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe\n\nCall of_node_put(platform_node) to avoid refcount leak in\nthe error path.(CVE-2022-49514)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: avoid null dereference in deinit\n\nIf venus_probe fails at pm_runtime_put_sync the error handling first\ncalls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets\ncore-\u0026gt;ops to NULL, hfi_core_deinit cannot call the core_deinit function\nanymore.\n\nAvoid this null pointer derefence by skipping the call when necessary.(CVE-2022-49527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes\n\ndrm_cvt_mode may return NULL and we should check it.\n\nThis bug is found by syzkaller:\n\nFAULT_INJECTION stacktrace:\n[ 168.567394] FAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 1\n[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1\n[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n[ 168.567408] Call trace:\n[ 168.567414] dump_backtrace+0x0/0x310\n[ 168.567418] show_stack+0x28/0x38\n[ 168.567423] dump_stack+0xec/0x15c\n[ 168.567427] should_fail+0x3ac/0x3d0\n[ 168.567437] __should_failslab+0xb8/0x120\n[ 168.567441] should_failslab+0x28/0xc0\n[ 168.567445] kmem_cache_alloc_trace+0x50/0x640\n[ 168.567454] drm_mode_create+0x40/0x90\n[ 168.567458] drm_cvt_mode+0x48/0xc78\n[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]\n[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80\n[ 168.567492] drm_mode_getconnector+0x2e0/0xa70\n[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8\n[ 168.567514] drm_ioctl+0x558/0x6d0\n[ 168.567522] do_vfs_ioctl+0x160/0xf30\n[ 168.567525] ksys_ioctl+0x98/0xd8\n[ 168.567530] __arm64_sys_ioctl+0x50/0xc8\n[ 168.567536] el0_svc_common+0xc8/0x320\n[ 168.567540] el0_svc_handler+0xf8/0x160\n[ 168.567544] el0_svc+0x10/0x218\n\nKASAN stacktrace:\n[ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]\n[ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425\n[ 168.567566]\n[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1\n[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n[ 168.567575] Call trace:\n[ 168.567578] dump_backtrace+0x0/0x310\n[ 168.567582] show_stack+0x28/0x38\n[ 168.567586] dump_stack+0xec/0x15c\n[ 168.567591] kasan_report+0x244/0x2f0\n[ 168.567594] __asan_load4+0x58/0xb0\n[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]\n[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80\n[ 168.567617] drm_mode_getconnector+0x2e0/0xa70\n[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8\n[ 168.567624] drm_ioctl+0x558/0x6d0\n[ 168.567628] do_vfs_ioctl+0x160/0xf30\n[ 168.567632] ksys_ioctl+0x98/0xd8\n[ 168.567636] __arm64_sys_ioctl+0x50/0xc8\n[ 168.567641] el0_svc_common+0xc8/0x320\n[ 168.567645] el0_svc_handler+0xf8/0x160\n[ 168.567649] el0_svc+0x10/0x218(CVE-2022-49532)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipw2x00: Fix potential NULL dereference in libipw_xmit()\n\ncrypt and crypt-\u0026gt;ops could be null, so we need to checking null\nbefore dereference(CVE-2022-49544)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: Fix buffer overflow in be_get_module_eeprom\n\nbe_cmd_read_port_transceiver_data assumes that it is given a buffer that\nis at least PAGE_DATA_LEN long, or twice that if the module supports SFF\n8472. However, this is not always the case.\n\nFix this by passing the desired offset and length to\nbe_cmd_read_port_transceiver_data so that we only copy the bytes once.(CVE-2022-49581)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: ralink: Check for null return of devm_kcalloc\n\nBecause of the possible failure of the allocation, data-\u0026gt;domains might\nbe NULL pointer and will cause the dereference of the NULL pointer\nlater.\nTherefore, it might be better to check it and directly return -ENOMEM\nwithout releasing data manually if fails, because the comment of the\ndevm_kmalloc() says \u0026quot;Memory allocated with this function is\nautomatically freed on driver detach.\u0026quot;.(CVE-2022-49608)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxtensa: Fix refcount leak bug in time.c\n\nIn calibrate_ccount(), of_find_compatible_node() will return a node\npointer with refcount incremented. We should use of_node_put() when\nit is not used anymore.(CVE-2022-49682)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix call trace in setup_tx_descriptors\n\nAfter PF reset and ethtool -t there was call trace in dmesg\nsometimes leading to panic. When there was some time, around 5\nseconds, between reset and test there were no errors.\n\nProblem was that pf reset calls i40e_vsi_close in prep_for_reset\nand ethtool -t calls i40e_vsi_close in diag_test. If there was not\nenough time between those commands the second i40e_vsi_close starts\nbefore previous i40e_vsi_close was done which leads to crash.\n\nAdd check to diag_test if pf is in reset and don\u0026apos;t start offline\ntests if it is true.\nAdd netif_info(\u0026quot;testing failed\u0026quot;) into unhappy path of i40e_diag_test()(CVE-2022-49725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred\n\nSimilar to the handling of play_deferred in commit 19cfe912c37b\n(\u0026quot;Bluetooth: btusb: Fix memory leak in play_deferred\u0026quot;), we thought\na patch might be needed here as well.\n\nCurrently usb_submit_urb is called directly to submit deferred tx\nurbs after unanchor them.\n\nSo the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb\nand cause memory leak.\n\nPut those urbs in tx_anchor to avoid the leak, and also fix the error\nhandling.(CVE-2022-49729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc\n\nA NULL sock pointer is passed into l2cap_sock_alloc() when it is called\nfrom l2cap_sock_new_connection_cb() and the error handling paths should\nalso be aware of it.\n\nSeemingly a more elegant solution would be to swap bt_sock_alloc() and\nl2cap_chan_create() calls since they are not interdependent to that moment\nbut then l2cap_chan_create() adds the soon to be deallocated and still\ndummy-initialized channel to the global list accessible by many L2CAP\npaths. The channel would be removed from the list in short period of time\nbut be a bit more straight-forward here and just check for NULL instead of\nchanging the order of function calls.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE static\nanalysis tool.(CVE-2024-58009)\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)",
"id": "OESA-2025-1317",
"modified": "2026-08-06T11:08:25Z",
"published": "2025-03-21T11:08:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1317"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47634"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47656"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49248"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49276"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49277"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49315"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49324"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49375"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49414"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49488"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49513"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49514"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49532"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49544"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49581"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49608"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49682"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49725"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58009"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
}
],
"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-47634",
"CVE-2021-47656",
"CVE-2022-49052",
"CVE-2022-49087",
"CVE-2022-49155",
"CVE-2022-49248",
"CVE-2022-49276",
"CVE-2022-49277",
"CVE-2022-49315",
"CVE-2022-49324",
"CVE-2022-49331",
"CVE-2022-49375",
"CVE-2022-49414",
"CVE-2022-49488",
"CVE-2022-49489",
"CVE-2022-49513",
"CVE-2022-49514",
"CVE-2022-49527",
"CVE-2022-49532",
"CVE-2022-49544",
"CVE-2022-49581",
"CVE-2022-49608",
"CVE-2022-49682",
"CVE-2022-49725",
"CVE-2022-49729",
"CVE-2024-58009",
"CVE-2025-21791"
]
}
OESA-2025-1371 (CVE-2024-57924)
Vulnerability from osv_openeuler – Published: 2025-04-03 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
fs: relax assertions on failure to encode file handles
Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.
The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.
There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.
The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.
The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.
Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit.
Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.(CVE-2024-57924)
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:
media: uvcvideo: Fix double free in error path
If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it.
Reviewed by: Ricardo Ribalda <ribalda@chromium.org>(CVE-2024-57980)
In the Linux kernel, the following vulnerability has been resolved:
tpm: Change to kvalloc() in eventlog/acpi.c
The following failure was reported on HPE ProLiant D320:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().(CVE-2024-58005)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: Add NULL check in mt_input_configured
devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.(CVE-2024-58020)
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:
ASoC: soc-pcm: don't use soc_pcm_ret() on .prepare callback
commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port" log severity") ignores -EINVAL error message on common soc_pcm_ret(). It is used from many functions, ignoring -EINVAL is over-kill.
The reason why -EINVAL was ignored was it really should only be used upon invalid parameters coming from userspace and in that case we don't want to log an error since we do not want to give userspace a way to do a denial-of-service attack on the syslog / diskspace.
So don't use soc_pcm_ret() on .prepare callback is better idea.(CVE-2024-58077)
In the Linux kernel, the following vulnerability has been resolved:
misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors
misc_minor_alloc was allocating id using ida for minor only in case of MISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids using ida_free causing a mismatch and following warn: > > WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f > > ida_free called for id=127 which is not allocated. > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ... > > [<60941eb4>] ida_free+0x3e0/0x41f > > [<605ac993>] misc_minor_free+0x3e/0xbc > > [<605acb82>] misc_deregister+0x171/0x1b3
misc_minor_alloc is changed to allocate id from ida for all minors falling in the range of dynamic/ misc dynamic minors(CVE-2024-58078)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double free of TCP_Server_Info::hostname
When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen:
RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK>(CVE-2025-21673)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel
Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues: 1. In SA add section, the should be _bh() variant when marking SA mode. 2. There is not needed flush_workqueue in SA delete routine. It is not needed as at this stage as it is removed from SADB and the running work will be canceled later in SA free.
===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted
charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]
and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 which would create a new lock dependency: (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3}
but this new dependency connects a SOFTIRQ-irq-safe lock: (&x->lock){+.-.}-{3:3}
... which became SOFTIRQ-irq-safe at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60 hrtimer_run_softirq+0x146/0x2e0 handle_softirqs+0x266/0x860 irq_exit_rcu+0x115/0x1a0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 default_idle+0x13/0x20 default_idle_call+0x67/0xa0 do_idle+0x2da/0x320 cpu_startup_entry+0x50/0x60 start_secondary+0x213/0x2a0 common_startup_64+0x129/0x138
to a SOFTIRQ-irq-unsafe lock: (&xa->xa_lock#24){+.+.}-{3:3}
... which became SOFTIRQ-irq-unsafe at: ... lock_acquire+0x1be/0x520 _raw_spin_lock+0x2c/0x40 xa_set_mark+0x70/0x110 mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core] xfrm_dev_state_add+0x3bb/0xd70 xfrm_add_sa+0x2451/0x4a90 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&xa->xa_lock#24); local_irq_disable(); lock(&x->lock); lock(&xa->xa_lock#24); <Interrupt> lock(&x->lock);
*** DEADLOCK ***
2 locks held by charon/1337: #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30
the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_alloc_spi+0xc0/0xe60 xfrm_alloc_userspi+0x5f6/0xbc0 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 IN-SOFTIRQ-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60
---truncated---(CVE-2025-21674)
In the Linux kernel, the following vulnerability has been resolved:
pktgen: Avoid out-of-bounds access in get_imix_entries
Passing a sufficient amount of imix entries leads to invalid access to the pkt_dev->imix_entries array because of the incorrect boundary check.
UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imix_pkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl lib/dump_stack.c:117 __ubsan_handle_out_of_bounds lib/ubsan.c:429 get_imix_entries net/core/pktgen.c:874 pktgen_if_write net/core/pktgen.c:1063 pde_write fs/proc/inode.c:334 proc_reg_write fs/proc/inode.c:346 vfs_write fs/read_write.c:593 ksys_write fs/read_write.c:644 do_syscall_64 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130
Found by Linux Verification Center (linuxtesting.org) with SVACE.
fp: allow to fill the array completely; minor changelog cleanup
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix lockup on tx to unregistering netdev with carrier
Commit in a fixes tag attempted to fix the issue in the following sequence of calls:
do_output
-> ovs_vport_send
-> dev_queue_xmit
-> __dev_queue_xmit
-> netdev_core_pick_tx
-> skb_tx_hash
When device is unregistering, the 'dev->real_num_tx_queues' goes to zero and the 'while (unlikely(hash >= qcount))' loop inside the 'skb_tx_hash' becomes infinite, locking up the core forever.
But unfortunately, checking just the carrier status is not enough to fix the issue, because some devices may still be in unregistering state while reporting carrier status OK.
One example of such device is a net/dummy. It sets carrier ON on start, but it doesn't implement .ndo_stop to set the carrier off. And it makes sense, because dummy doesn't really have a carrier. Therefore, while this device is unregistering, it's still easy to hit the infinite loop in the skb_tx_hash() from the OVS datapath. There might be other drivers that do the same, but dummy by itself is important for the OVS ecosystem, because it is frequently used as a packet sink for tcpdump while debugging OVS deployments. And when the issue is hit, the only way to recover is to reboot.
Fix that by also checking if the device is running. The running state is handled by the net core during unregistering, so it covers unregistering case better, and we don't really need to send packets to devices that are not running anyway.
While only checking the running state might be enough, the carrier check is preserved. The running and the carrier states seem disjoined throughout the code and different drivers. And other core functions like __dev_direct_xmit() check both before attempting to transmit a packet. So, it seems safer to check both flags in OVS as well.(CVE-2025-21681)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpf_sk_select_reuseport() memory leak
As pointed out in the original comment, lookup in sockmap can return a TCP ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb does not imply a non-refcounted socket.
Drop sk's reference in both error paths.
unreferenced object 0xffff888101911800 (size 2048): comm "test_progs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21683)
In the Linux kernel, the following vulnerability has been resolved:
cachestat: fix page cache statistics permission checking
When the 'cachestat()' system call was added in commit cf264e1329fb ("cachestat: implement cachestat syscall"), it was meant to be a much more convenient (and performant) version of mincore() that didn't need mapping things into the user virtual address space in order to work.
But it ended up missing the "check for writability or ownership" fix for mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore() more conservative").
This just adds equivalent logic to 'cachestat()', modified for the file context (rather than vma).(CVE-2025-21691)
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:
misc: fastrpc: Fix copy buffer page size
For non-registered buffer, fastrpc driver copies the buffer and pass it to the remote subsystem. There is a problem with current implementation of page size calculation which is not considering the offset in the calculation. This might lead to passing of improper and out-of-bounds page size which could result in memory issue. Calculate page start and page end using the offset adjusted address instead of absolute address.(CVE-2025-21734)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-sff: Ensure that we cannot write outside the allocated buffer
reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to write outside the allocated buffer, overwriting random memory.
While a ATA device is supposed to abort a ATA_NOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by ata_sff_hsm_move(). Anyway, that is most likely a separate bug.
Looking at __atapi_pio_bytes(), it already has a safety check to ensure that __atapi_pio_bytes() cannot write outside the allocated buffer.
Add a similar check to ata_pio_sector(), such that also ata_pio_sector() cannot write outside the allocated buffer.(CVE-2025-21738)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix assertion failure when splitting ordered extent after transaction abort
If while we are doing a direct IO write a transaction abort happens, we mark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done at btrfs_destroy_ordered_extents()), and then after that if we enter btrfs_split_ordered_extent() and the ordered extent has bytes left (meaning we have a bio that doesn't cover the whole ordered extent, see details at btrfs_extract_ordered_extent()), we will fail on the following assertion at btrfs_split_ordered_extent():
ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS));
because the BTRFS_ORDERED_IOERR flag is set and the definition of BTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the type of write (regular, nocow, prealloc, compressed, direct IO, encoded).
Fix this by returning an error from btrfs_extract_ordered_extent() if we find the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will be the error that resulted in the transaction abort or -EIO if no transaction abort happened.
This was recently reported by syzbot with the following trace:
FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:53 [inline] should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 should_failslab+0xac/0x100 mm/failslab.c:46 slab_pre_alloc_hook mm/slub.c:4072 [inline] slab_alloc_node mm/slub.c:4148 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 check_system_chunk fs/btrfs/block-group.c:4319 [inline] do_chunk_alloc fs/btrfs/block-group.c:3891 [inline] btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline] find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline] btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [inline] __do_sys_pwritev2 fs/read_write.c:1204 [inline] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 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:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 </TASK> BTRFS error (device loop0 state A): Transaction aborted (error -12) BTRFS: error (device loop0 state A ---truncated---(CVE-2025-21754)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Keep the binding until socket destruction
Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().
Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:
1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
2. transport->release() calls vsock_remove_bound() without checking if
sk was bound and moved to bound list (refcnt=1)
3. vsock_bind() assumes sk is in unbound list and before
__vsock_insert_bound(vsock_bound_sockets()) calls
__vsock_remove_bound() which does:
list_del_init(&vsk->bound_table); // nop
sock_put(&vsk->sk); // refcnt=0
BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Allocated by task 2057: 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 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 2057: 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 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21756)
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:
team: better TEAM_OPTION_TYPE_STRING validation
syzbot reported following splat [1]
Make sure user-provided data contains one nul byte.
[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 _syssendmsg+0x877/0xb60 net/socket.c:2573 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 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-2025-21787)
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:
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:
tty: xilinx_uartps: split sysrq handling
lockdep detects the following circular locking dependency:
CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()
The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock.
Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.(CVE-2025-21820)
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:
block: don't revert iter for -EIOCBQUEUED
blkdev_read_iter() has a few odd checks, like gating the position and count adjustment on whether or not the result is bigger-than-or-equal to zero (where bigger than makes more sense), and not checking the return value of blkdev_direct_IO() before doing an iov_iter_revert(). The latter can lead to attempting to revert with a negative value, which when passed to iov_iter_revert() as an unsigned value will lead to throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.
Be sane and don't revert for -EIOCBQUEUED, like what is done in other spots.(CVE-2025-21832)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Add check for next_buffer in receive_encrypted_standard()
Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.(CVE-2025-21844)
In the Linux kernel, the following vulnerability has been resolved:
acct: perform last write from workqueue
In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs.
Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk.
This api should stop to exist though.(CVE-2025-21846)
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: add release function for struct device
According to device_release() in /drivers/base/core.c, a device without a release function is a broken device and must be fixed.
The current code directly frees the device after calling device_add() without waiting for other kernel parts to release their references. Thus, a reference could still be held to a struct device, e.g., by sysfs, leading to potential use-after-free issues if a proper release function is not set.(CVE-2025-21856)
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:
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:
perf/core: Add RCU read lock protection to perf_iterate_ctx()
The perf_iterate_ctx() function performs RCU list traversal but currently lacks RCU read lock protection. This causes lockdep warnings when running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:
WARNING: suspicious RCU usage
kernel/events/core.c:8168 RCU-list traversed in non-reader section!!
Call Trace:
lockdep_rcu_suspicious
? perf_event_addr_filters_apply
perf_iterate_ctx
perf_event_exec
begin_new_exec
? load_elf_phdrs
load_elf_binary
? lock_acquire
? find_held_lock
? bprm_execve
bprm_execve
do_execveat_common.isra.0
__x64_sys_execve
do_syscall_64
entry_SYSCALL_64_after_hwframe
This protection was previously present but was removed in commit bd2756811766 ("perf: Rewrite core context handling"). Add back the necessary rcu_read_lock()/rcu_read_unlock() pair around perf_iterate_ctx() call in perf_event_exec().
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-source-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"perf-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"python3-perf-6.6.0-85.0.0.79.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-85.0.0.79.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-85.0.0.79.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-source-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"perf-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"python3-perf-6.6.0-85.0.0.79.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-85.0.0.79.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-85.0.0.79.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\nfs: relax assertions on failure to encode file handles\n\nEncoding file handles is usually performed by a filesystem \u0026gt;encode_fh()\nmethod that may fail for various reasons.\n\nThe legacy users of exportfs_encode_fh(), namely, nfsd and\nname_to_handle_at(2) syscall are ready to cope with the possibility\nof failure to encode a file handle.\n\nThere are a few other users of exportfs_encode_{fh,fid}() that\ncurrently have a WARN_ON() assertion when -\u0026gt;encode_fh() fails.\nRelax those assertions because they are wrong.\n\nThe second linked bug report states commit 16aac5ad1fa9 (\u0026quot;ovl: support\nencoding non-decodable file handles\u0026quot;) in v6.6 as the regressing commit,\nbut this is not accurate.\n\nThe aforementioned commit only increases the chances of the assertion\nand allows triggering the assertion with the reproducer using overlayfs,\ninotify and drop_caches.\n\nTriggering this assertion was always possible with other filesystems and\nother reasons of -\u0026gt;encode_fh() failures and more particularly, it was\nalso possible with the exact same reproducer using overlayfs that is\nmounted with options index=on,nfs_export=on also on kernels \u0026lt; v6.6.\nTherefore, I am not listing the aforementioned commit as a Fixes commit.\n\nBackport hint: this patch will have a trivial conflict applying to\nv6.6.y, and other trivial conflicts applying to stable kernels \u0026lt; v6.6.(CVE-2024-57924)\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\nmedia: uvcvideo: Fix double free in error path\n\nIf the uvc_status_init() function fails to allocate the int_urb, it will\nfree the dev-\u0026gt;status pointer but doesn\u0026apos;t reset the pointer to NULL. This\nresults in the kfree() call in uvc_status_cleanup() trying to\ndouble-free the memory. Fix it by resetting the dev-\u0026gt;status pointer to\nNULL after freeing it.\n\nReviewed by: Ricardo Ribalda \u0026lt;ribalda@chromium.org\u0026gt;(CVE-2024-57980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Change to kvalloc() in eventlog/acpi.c\n\nThe following failure was reported on HPE ProLiant D320:\n\n[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)\n[ 10.848132][ T1] ------------[ cut here ]------------\n[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330\n[ 10.862827][ T1] Modules linked in:\n[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375\n[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024\n[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330\n[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 \u0026lt;0f\u0026gt; 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1\n[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246\n[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000\n[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0\n\nThe above transcript shows that ACPI pointed a 16 MiB buffer for the log\nevents because RSI maps to the \u0026apos;order\u0026apos; parameter of __alloc_pages_noprof().\nAddress the bug by moving from devm_kmalloc() to devm_add_action() and\nkvmalloc() and devm_add_action().(CVE-2024-58005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Add NULL check in mt_input_configured\n\ndevm_kasprintf() can return a NULL pointer on failure,but this\nreturned value in mt_input_configured() is not checked.\nAdd NULL check in mt_input_configured(), to handle kernel NULL\npointer dereference error.(CVE-2024-58020)\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\nASoC: soc-pcm: don\u0026apos;t use soc_pcm_ret() on .prepare callback\n\ncommit 1f5664351410 (\u0026quot;ASoC: lower \u0026quot;no backend DAIs enabled for ... Port\u0026quot;\nlog severity\u0026quot;) ignores -EINVAL error message on common soc_pcm_ret().\nIt is used from many functions, ignoring -EINVAL is over-kill.\n\nThe reason why -EINVAL was ignored was it really should only be used\nupon invalid parameters coming from userspace and in that case we don\u0026apos;t\nwant to log an error since we do not want to give userspace a way to do\na denial-of-service attack on the syslog / diskspace.\n\nSo don\u0026apos;t use soc_pcm_ret() on .prepare callback is better idea.(CVE-2024-58077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors\n\nmisc_minor_alloc was allocating id using ida for minor only in case of\nMISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids\nusing ida_free causing a mismatch and following warn:\n\u0026gt; \u0026gt; WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f\n\u0026gt; \u0026gt; ida_free called for id=127 which is not allocated.\n\u0026gt; \u0026gt; \u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\n...\n\u0026gt; \u0026gt; [\u0026lt;60941eb4\u0026gt;] ida_free+0x3e0/0x41f\n\u0026gt; \u0026gt; [\u0026lt;605ac993\u0026gt;] misc_minor_free+0x3e/0xbc\n\u0026gt; \u0026gt; [\u0026lt;605acb82\u0026gt;] misc_deregister+0x171/0x1b3\n\nmisc_minor_alloc is changed to allocate id from ida for all minors\nfalling in the range of dynamic/ misc dynamic minors(CVE-2024-58078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double free of TCP_Server_Info::hostname\n\nWhen shutting down the server in cifs_put_tcp_session(), cifsd thread\nmight be reconnecting to multiple DFS targets before it realizes it\nshould exit the loop, so @server-\u0026gt;hostname can\u0026apos;t be freed as long as\ncifsd thread isn\u0026apos;t done. Otherwise the following can happen:\n\n RIP: 0010:__slab_free+0x223/0x3c0\n Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89\n 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff \u0026lt;0f\u0026gt;\n 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80\n RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246\n RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068\n RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400\n RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000\n R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500\n R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068\n FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000)\n 000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4:\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? show_trace_log_lvl+0x1c4/0x2df\n ? show_trace_log_lvl+0x1c4/0x2df\n ? __reconnect_target_unlocked+0x3e/0x160 [cifs]\n ? __die_body.cold+0x8/0xd\n ? die+0x2b/0x50\n ? do_trap+0xce/0x120\n ? __slab_free+0x223/0x3c0\n ? do_error_trap+0x65/0x80\n ? __slab_free+0x223/0x3c0\n ? exc_invalid_op+0x4e/0x70\n ? __slab_free+0x223/0x3c0\n ? asm_exc_invalid_op+0x16/0x20\n ? __slab_free+0x223/0x3c0\n ? extract_hostname+0x5c/0xa0 [cifs]\n ? extract_hostname+0x5c/0xa0 [cifs]\n ? __kmalloc+0x4b/0x140\n __reconnect_target_unlocked+0x3e/0x160 [cifs]\n reconnect_dfs_server+0x145/0x430 [cifs]\n cifs_handle_standard+0x1ad/0x1d0 [cifs]\n cifs_demultiplex_thread+0x592/0x730 [cifs]\n ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]\n kthread+0xdd/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x29/0x50\n \u0026lt;/TASK\u0026gt;(CVE-2025-21673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel\n\nAttempt to enable IPsec packet offload in tunnel mode in debug kernel\ngenerates the following kernel panic, which is happening due to two\nissues:\n1. In SA add section, the should be _bh() variant when marking SA mode.\n2. There is not needed flush_workqueue in SA delete routine. It is not\nneeded as at this stage as it is removed from SADB and the running work\nwill be canceled later in SA free.\n\n =====================================================\n WARNING: SOFTIRQ-safe -\u0026gt; SOFTIRQ-unsafe lock order detected\n 6.12.0+ #4 Not tainted\n -----------------------------------------------------\n charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:\n ffff88810f365020 (\u0026amp;xa-\u0026gt;xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]\n\n and this task is already holding:\n ffff88813e0f0d48 (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n which would create a new lock dependency:\n (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3} -\u0026gt; (\u0026amp;xa-\u0026gt;xa_lock#24){+.+.}-{3:3}\n\n but this new dependency connects a SOFTIRQ-irq-safe lock:\n (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3}\n\n ... which became SOFTIRQ-irq-safe at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_timer_handler+0x91/0xd70\n __hrtimer_run_queues+0x1dd/0xa60\n hrtimer_run_softirq+0x146/0x2e0\n handle_softirqs+0x266/0x860\n irq_exit_rcu+0x115/0x1a0\n sysvec_apic_timer_interrupt+0x6e/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n default_idle+0x13/0x20\n default_idle_call+0x67/0xa0\n do_idle+0x2da/0x320\n cpu_startup_entry+0x50/0x60\n start_secondary+0x213/0x2a0\n common_startup_64+0x129/0x138\n\n to a SOFTIRQ-irq-unsafe lock:\n (\u0026amp;xa-\u0026gt;xa_lock#24){+.+.}-{3:3}\n\n ... which became SOFTIRQ-irq-unsafe at:\n ...\n lock_acquire+0x1be/0x520\n _raw_spin_lock+0x2c/0x40\n xa_set_mark+0x70/0x110\n mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]\n xfrm_dev_state_add+0x3bb/0xd70\n xfrm_add_sa+0x2451/0x4a90\n xfrm_user_rcv_msg+0x493/0x880\n netlink_rcv_skb+0x12e/0x380\n xfrm_netlink_rcv+0x6d/0x90\n netlink_unicast+0x42f/0x740\n netlink_sendmsg+0x745/0xbe0\n __sock_sendmsg+0xc5/0x190\n __sys_sendto+0x1fe/0x2c0\n __x64_sys_sendto+0xdc/0x1b0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n other info that might help us debug this:\n\n Possible interrupt unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;xa-\u0026gt;xa_lock#24);\n local_irq_disable();\n lock(\u0026amp;x-\u0026gt;lock);\n lock(\u0026amp;xa-\u0026gt;xa_lock#24);\n \u0026lt;Interrupt\u0026gt;\n lock(\u0026amp;x-\u0026gt;lock);\n\n *** DEADLOCK ***\n\n 2 locks held by charon/1337:\n #0: ffffffff87f8f858 (\u0026amp;net-\u0026gt;xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90\n #1: ffff88813e0f0d48 (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n\n the dependencies between SOFTIRQ-irq-safe lock and the holding lock:\n -\u0026gt; (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3} ops: 29 {\n HARDIRQ-ON-W at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_alloc_spi+0xc0/0xe60\n xfrm_alloc_userspi+0x5f6/0xbc0\n xfrm_user_rcv_msg+0x493/0x880\n netlink_rcv_skb+0x12e/0x380\n xfrm_netlink_rcv+0x6d/0x90\n netlink_unicast+0x42f/0x740\n netlink_sendmsg+0x745/0xbe0\n __sock_sendmsg+0xc5/0x190\n __sys_sendto+0x1fe/0x2c0\n __x64_sys_sendto+0xdc/0x1b0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n IN-SOFTIRQ-W at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_timer_handler+0x91/0xd70\n __hrtimer_run_queues+0x1dd/0xa60\n \n---truncated---(CVE-2025-21674)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npktgen: Avoid out-of-bounds access in get_imix_entries\n\nPassing a sufficient amount of imix entries leads to invalid access to the\npkt_dev-\u0026gt;imix_entries array because of the incorrect boundary check.\n\nUBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24\nindex 20 is out of range for type \u0026apos;imix_pkt [20]\u0026apos;\nCPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl lib/dump_stack.c:117\n__ubsan_handle_out_of_bounds lib/ubsan.c:429\nget_imix_entries net/core/pktgen.c:874\npktgen_if_write net/core/pktgen.c:1063\npde_write fs/proc/inode.c:334\nproc_reg_write fs/proc/inode.c:346\nvfs_write fs/read_write.c:593\nksys_write fs/read_write.c:644\ndo_syscall_64 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[ fp: allow to fill the array completely; minor changelog cleanup ](CVE-2025-21680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix lockup on tx to unregistering netdev with carrier\n\nCommit in a fixes tag attempted to fix the issue in the following\nsequence of calls:\n\n do_output\n -\u0026gt; ovs_vport_send\n -\u0026gt; dev_queue_xmit\n -\u0026gt; __dev_queue_xmit\n -\u0026gt; netdev_core_pick_tx\n -\u0026gt; skb_tx_hash\n\nWhen device is unregistering, the \u0026apos;dev-\u0026gt;real_num_tx_queues\u0026apos; goes to\nzero and the \u0026apos;while (unlikely(hash \u0026gt;= qcount))\u0026apos; loop inside the\n\u0026apos;skb_tx_hash\u0026apos; becomes infinite, locking up the core forever.\n\nBut unfortunately, checking just the carrier status is not enough to\nfix the issue, because some devices may still be in unregistering\nstate while reporting carrier status OK.\n\nOne example of such device is a net/dummy. It sets carrier ON\non start, but it doesn\u0026apos;t implement .ndo_stop to set the carrier off.\nAnd it makes sense, because dummy doesn\u0026apos;t really have a carrier.\nTherefore, while this device is unregistering, it\u0026apos;s still easy to hit\nthe infinite loop in the skb_tx_hash() from the OVS datapath. There\nmight be other drivers that do the same, but dummy by itself is\nimportant for the OVS ecosystem, because it is frequently used as a\npacket sink for tcpdump while debugging OVS deployments. And when the\nissue is hit, the only way to recover is to reboot.\n\nFix that by also checking if the device is running. The running\nstate is handled by the net core during unregistering, so it covers\nunregistering case better, and we don\u0026apos;t really need to send packets\nto devices that are not running anyway.\n\nWhile only checking the running state might be enough, the carrier\ncheck is preserved. The running and the carrier states seem disjoined\nthroughout the code and different drivers. And other core functions\nlike __dev_direct_xmit() check both before attempting to transmit\na packet. So, it seems safer to check both flags in OVS as well.(CVE-2025-21681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix bpf_sk_select_reuseport() memory leak\n\nAs pointed out in the original comment, lookup in sockmap can return a TCP\nESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF\nset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb\ndoes not imply a non-refcounted socket.\n\nDrop sk\u0026apos;s reference in both error paths.\n\nunreferenced object 0xffff888101911800 (size 2048):\n comm \u0026quot;test_progs\u0026quot;, pid 44109, jiffies 4297131437\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 9336483b):\n __kmalloc_noprof+0x3bf/0x560\n __reuseport_alloc+0x1d/0x40\n reuseport_alloc+0xca/0x150\n reuseport_attach_prog+0x87/0x140\n sk_reuseport_attach_bpf+0xc8/0x100\n sk_setsockopt+0x1181/0x1990\n do_sock_setsockopt+0x12b/0x160\n __sys_setsockopt+0x7b/0xc0\n __x64_sys_setsockopt+0x1b/0x30\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncachestat: fix page cache statistics permission checking\n\nWhen the \u0026apos;cachestat()\u0026apos; system call was added in commit cf264e1329fb\n(\u0026quot;cachestat: implement cachestat syscall\u0026quot;), it was meant to be a much\nmore convenient (and performant) version of mincore() that didn\u0026apos;t need\nmapping things into the user virtual address space in order to work.\n\nBut it ended up missing the \u0026quot;check for writability or ownership\u0026quot; fix for\nmincore(), done in commit 134fca9063ad (\u0026quot;mm/mincore.c: make mincore()\nmore conservative\u0026quot;).\n\nThis just adds equivalent logic to \u0026apos;cachestat()\u0026apos;, modified for the file\ncontext (rather than vma).(CVE-2025-21691)\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\nmisc: fastrpc: Fix copy buffer page size\n\nFor non-registered buffer, fastrpc driver copies the buffer and\npass it to the remote subsystem. There is a problem with current\nimplementation of page size calculation which is not considering\nthe offset in the calculation. This might lead to passing of\nimproper and out-of-bounds page size which could result in\nmemory issue. Calculate page start and page end using the offset\nadjusted address instead of absolute address.(CVE-2025-21734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-sff: Ensure that we cannot write outside the allocated buffer\n\nreveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len\nset to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to\nATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to\nwrite outside the allocated buffer, overwriting random memory.\n\nWhile a ATA device is supposed to abort a ATA_NOP command, there does seem\nto be a bug either in libata-sff or QEMU, where either this status is not\nset, or the status is cleared before read by ata_sff_hsm_move().\nAnyway, that is most likely a separate bug.\n\nLooking at __atapi_pio_bytes(), it already has a safety check to ensure\nthat __atapi_pio_bytes() cannot write outside the allocated buffer.\n\nAdd a similar check to ata_pio_sector(), such that also ata_pio_sector()\ncannot write outside the allocated buffer.(CVE-2025-21738)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix assertion failure when splitting ordered extent after transaction abort\n\nIf while we are doing a direct IO write a transaction abort happens, we\nmark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done\nat btrfs_destroy_ordered_extents()), and then after that if we enter\nbtrfs_split_ordered_extent() and the ordered extent has bytes left\n(meaning we have a bio that doesn\u0026apos;t cover the whole ordered extent, see\ndetails at btrfs_extract_ordered_extent()), we will fail on the following\nassertion at btrfs_split_ordered_extent():\n\n ASSERT(!(flags \u0026amp; ~BTRFS_ORDERED_TYPE_FLAGS));\n\nbecause the BTRFS_ORDERED_IOERR flag is set and the definition of\nBTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the\ntype of write (regular, nocow, prealloc, compressed, direct IO, encoded).\n\nFix this by returning an error from btrfs_extract_ordered_extent() if we\nfind the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will\nbe the error that resulted in the transaction abort or -EIO if no\ntransaction abort happened.\n\nThis was recently reported by syzbot with the following trace:\n\n FAULT_INJECTION: forcing a failure.\n name failslab, interval 1, probability 0, space 0, times 1\n CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n Call 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 fail_dump lib/fault-inject.c:53 [inline]\n should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154\n should_failslab+0xac/0x100 mm/failslab.c:46\n slab_pre_alloc_hook mm/slub.c:4072 [inline]\n slab_alloc_node mm/slub.c:4148 [inline]\n __do_kmalloc_node mm/slub.c:4297 [inline]\n __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1037 [inline]\n btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742\n reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292\n check_system_chunk fs/btrfs/block-group.c:4319 [inline]\n do_chunk_alloc fs/btrfs/block-group.c:3891 [inline]\n btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187\n find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline]\n find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579\n btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672\n btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline]\n btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321\n btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525\n iomap_iter+0x697/0xf60 fs/iomap/iter.c:90\n __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702\n btrfs_dio_write fs/btrfs/direct-io.c:775 [inline]\n btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880\n btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397\n do_iter_readv_writev+0x600/0x880\n vfs_writev+0x376/0xba0 fs/read_write.c:1050\n do_pwritev fs/read_write.c:1146 [inline]\n __do_sys_pwritev2 fs/read_write.c:1204 [inline]\n __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195\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:0x7f1281f85d29\n RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148\n RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29\n RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005\n RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003\n R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002\n R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328\n \u0026lt;/TASK\u0026gt;\n BTRFS error (device loop0 state A): Transaction aborted (error -12)\n BTRFS: error (device loop0 state A\n---truncated---(CVE-2025-21754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Keep the binding until socket destruction\n\nPreserve sockets bindings; this includes both resulting from an explicit\nbind() and those implicitly bound through autobind during connect().\n\nPrevents socket unbinding during a transport reassignment, which fixes a\nuse-after-free:\n\n 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)\n 2. transport-\u0026gt;release() calls vsock_remove_bound() without checking if\n sk was bound and moved to bound list (refcnt=1)\n 3. vsock_bind() assumes sk is in unbound list and before\n __vsock_insert_bound(vsock_bound_sockets()) calls\n __vsock_remove_bound() which does:\n list_del_init(\u0026amp;vsk-\u0026gt;bound_table); // nop\n sock_put(\u0026amp;vsk-\u0026gt;sk); // refcnt=0\n\nBUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730\nRead of size 4 at addr ffff88816b46a74c by task a.out/2057\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n __vsock_bind+0x62e/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nAllocated by task 2057:\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 __vsock_create.constprop.0+0x2e/0xb60\n vsock_create+0xe4/0x420\n __sock_create+0x241/0x650\n __sys_socket+0xf2/0x1a0\n __x64_sys_socket+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 2057:\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 __vsock_bind+0x5e1/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150\nRIP: 0010:refcount_warn_saturate+0xce/0x150\n __vsock_bind+0x66d/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150\nRIP: 0010:refcount_warn_saturate+0xee/0x150\n vsock_remove_bound+0x187/0x1e0\n __vsock_release+0x383/0x4a0\n vsock_release+0x90/0x120\n __sock_release+0xa3/0x250\n sock_close+0x14/0x20\n __fput+0x359/0xa80\n task_work_run+0x107/0x1d0\n do_exit+0x847/0x2560\n do_group_exit+0xb8/0x250\n __x64_sys_exit_group+0x3a/0x50\n x64_sys_call+0xfec/0x14f0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21756)\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\nteam: better TEAM_OPTION_TYPE_STRING validation\n\nsyzbot reported following splat [1]\n\nMake sure user-provided data contains one nul byte.\n\n[1]\n BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline]\n BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714\n string_nocheck lib/vsprintf.c:633 [inline]\n string+0x3ec/0x5f0 lib/vsprintf.c:714\n vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843\n __request_module+0x252/0x9f0 kernel/module/kmod.c:149\n team_mode_get drivers/net/team/team_core.c:480 [inline]\n team_change_mode drivers/net/team/team_core.c:607 [inline]\n team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401\n team_option_set drivers/net/team/team_core.c:375 [inline]\n team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662\n genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543\n genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]\n netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348\n netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892\n sock_sendmsg_nosec net/socket.c:718 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:733\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2573\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627\n __sys_sendmsg net/socket.c:2659 [inline]\n __do_sys_sendmsg net/socket.c:2664 [inline]\n __se_sys_sendmsg net/socket.c:2662 [inline]\n __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662\n x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47\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-2025-21787)\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\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\ntty: xilinx_uartps: split sysrq handling\n\nlockdep detects the following circular locking dependency:\n\nCPU 0 CPU 1\n========================== ============================\ncdns_uart_isr() printk()\n uart_port_lock(port) console_lock()\n\t\t\t cdns_uart_console_write()\n if (!port-\u0026gt;sysrq)\n uart_port_lock(port)\n uart_handle_break()\n port-\u0026gt;sysrq = ...\n uart_handle_sysrq_char()\n printk()\n console_lock()\n\nThe fixed commit attempts to avoid this situation by only taking the\nport lock in cdns_uart_console_write if port-\u0026gt;sysrq unset. However, if\n(as shown above) cdns_uart_console_write runs before port-\u0026gt;sysrq is set,\nthen it will try to take the port lock anyway. This may result in a\ndeadlock.\n\nFix this by splitting sysrq handling into two parts. We use the prepare\nhelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)\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\nblock: don\u0026apos;t revert iter for -EIOCBQUEUED\n\nblkdev_read_iter() has a few odd checks, like gating the position and\ncount adjustment on whether or not the result is bigger-than-or-equal to\nzero (where bigger than makes more sense), and not checking the return\nvalue of blkdev_direct_IO() before doing an iov_iter_revert(). The\nlatter can lead to attempting to revert with a negative value, which\nwhen passed to iov_iter_revert() as an unsigned value will lead to\nthrowing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.\n\nBe sane and don\u0026apos;t revert for -EIOCBQUEUED, like what is done in other\nspots.(CVE-2025-21832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Add check for next_buffer in receive_encrypted_standard()\n\nAdd check for the return value of cifs_buf_get() and cifs_small_buf_get()\nin receive_encrypted_standard() to prevent null pointer dereference.(CVE-2025-21844)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nacct: perform last write from workqueue\n\nIn [1] it was reported that the acct(2) system call can be used to\ntrigger NULL deref in cases where it is set to write to a file that\ntriggers an internal lookup. This can e.g., happen when pointing acc(2)\nto /sys/power/resume. At the point the where the write to this file\nhappens the calling task has already exited and called exit_fs(). A\nlookup will thus trigger a NULL-deref when accessing current-\u0026gt;fs.\n\nReorganize the code so that the the final write happens from the\nworkqueue but with the caller\u0026apos;s credentials. This preserves the\n(strange) permission model and has almost no regression risk.\n\nThis api should stop to exist though.(CVE-2025-21846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/ism: add release function for struct device\n\nAccording to device_release() in /drivers/base/core.c,\na device without a release function is a broken device\nand must be fixed.\n\nThe current code directly frees the device after calling device_add()\nwithout waiting for other kernel parts to release their references.\nThus, a reference could still be held to a struct device,\ne.g., by sysfs, leading to potential use-after-free\nissues if a proper release function is not set.(CVE-2025-21856)\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\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\nperf/core: Add RCU read lock protection to perf_iterate_ctx()\n\nThe perf_iterate_ctx() function performs RCU list traversal but\ncurrently lacks RCU read lock protection. This causes lockdep warnings\nwhen running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:\n\n\tWARNING: suspicious RCU usage\n\tkernel/events/core.c:8168 RCU-list traversed in non-reader section!!\n\n\t Call Trace:\n\t lockdep_rcu_suspicious\n\t ? perf_event_addr_filters_apply\n\t perf_iterate_ctx\n\t perf_event_exec\n\t begin_new_exec\n\t ? load_elf_phdrs\n\t load_elf_binary\n\t ? lock_acquire\n\t ? find_held_lock\n\t ? bprm_execve\n\t bprm_execve\n\t do_execveat_common.isra.0\n\t __x64_sys_execve\n\t do_syscall_64\n\t entry_SYSCALL_64_after_hwframe\n\nThis protection was previously present but was removed in commit\nbd2756811766 (\u0026quot;perf: Rewrite core context handling\u0026quot;). Add back the\nnecessary rcu_read_lock()/rcu_read_unlock() pair around\nperf_iterate_ctx() call in perf_event_exec().\n\n[ mingo: Use scoped_guard() as suggested by Peter ](CVE-2025-21889)",
"id": "OESA-2025-1371",
"modified": "2026-08-06T11:08:28Z",
"published": "2025-04-03T11:08:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1371"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21674"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21681"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21691"
},
{
"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-21734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21787"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21820"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21856"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21889"
}
],
"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-57924",
"CVE-2024-57951",
"CVE-2024-57980",
"CVE-2024-58005",
"CVE-2024-58020",
"CVE-2024-58055",
"CVE-2024-58077",
"CVE-2024-58078",
"CVE-2025-21673",
"CVE-2025-21674",
"CVE-2025-21680",
"CVE-2025-21681",
"CVE-2025-21683",
"CVE-2025-21691",
"CVE-2025-21718",
"CVE-2025-21722",
"CVE-2025-21734",
"CVE-2025-21738",
"CVE-2025-21754",
"CVE-2025-21756",
"CVE-2025-21785",
"CVE-2025-21787",
"CVE-2025-21791",
"CVE-2025-21816",
"CVE-2025-21820",
"CVE-2025-21823",
"CVE-2025-21832",
"CVE-2025-21844",
"CVE-2025-21846",
"CVE-2025-21856",
"CVE-2025-21863",
"CVE-2025-21887",
"CVE-2025-21889"
]
}
OESA-2025-1372 (CVE-2024-53174)
Vulnerability from osv_openeuler – Published: 2025-04-03 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: make sure cache entry active before cache_show
The function c_show was called with protection from RCU. This only
ensures that cp will not be freed. Therefore, the reference count for
cp can drop to zero, which will trigger a refcount use-after-free
warning when cache_get is called. To resolve this issue, use
cache_get_rcu to ensure that cp remains active.
------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120
Call Trace: <TASK> c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53174)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()
Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ip_vs_protocol_init(), triggering the following objtool warning during build time:
vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()
At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously.
Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated:
define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ...
14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23
20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ...
23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }
The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined:
%13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17
This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location:
define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ...
12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }
In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator.
Zero the on-stack buffer to avoid this possible UB.(CVE-2024-53680)
In the Linux kernel, the following vulnerability has been resolved:
net: avoid potential UAF in default_operstate()
syzbot reported an UAF in default_operstate() [1]
Issue is a race between device and netns dismantles.
After calling __rtnl_unlock() from netdev_run_todo(), we can not assume the netns of each device is still alive.
Make sure the device is not in NETREG_UNREGISTERED state, and add an ASSERT_RTNL() before the call to __dev_get_by_index().
We might move this ASSERT_RTNL() in __dev_get_by_index() in the future.
[1]
BUG: KASAN: slab-use-after-free in __dev_get_by_index+0x5d/0x110 net/core/dev.c:852 Read of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339
CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __dev_get_by_index+0x5d/0x110 net/core/dev.c:852 default_operstate net/core/link_watch.c:51 [inline] rfc2863_policy+0x224/0x300 net/core/link_watch.c:67 linkwatch_do_dev+0x3e/0x170 net/core/link_watch.c:170 netdev_run_todo+0x461/0x1000 net/core/dev.c:10894 rtnl_unlock net/core/rtnetlink.c:152 [inline] rtnl_net_unlock include/linux/rtnetlink.h:133 [inline] rtnl_dellink+0x760/0x8d0 net/core/rtnetlink.c:3520 rtnetlink_rcv_msg+0x791/0xcf0 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2541 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/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:0x7f2a3cb80809 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008 RBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8 </TASK>
Allocated by task 5339: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314 kmalloc_noprof include/linux/slab.h:901 [inline] kmalloc_array_noprof include/linux/slab.h:945 [inline] netdev_create_hash net/core/dev.c:11870 [inline] netdev_init+0x10c/0x250 net/core/dev.c:11890 ops_init+0x31e/0x590 net/core/net_namespace.c:138 setup_net+0x287/0x9e0 net/core/net_namespace.c:362 copy_net_ns+0x33f/0x570 net/core/net_namespace.c:500 create_new_namespaces+0x425/0x7b0 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x124/0x180 kernel/nsproxy.c:228 ksys_unshare+0x57d/0xa70 kernel/fork.c:3314 __do_sys_unshare kernel/fork.c:3385 [inline] __se_sys_unshare kernel/fork.c:3383 [inline] __x64_sys_unshare+0x38/0x40 kernel/fork.c:3383 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x8 ---truncated---(CVE-2024-56635)
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix recursive lock when verdict program return SK_PASS
When the stream_verdict program returns SK_PASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9.
''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock
'''
This topic has been discussed before, but it has not been fixed. Previous discussion: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch(CVE-2024-56694)
In the Linux kernel, the following vulnerability has been resolved:
fs: relax assertions on failure to encode file handles
Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.
The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.
There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.
The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.
The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.
Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit.
Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.(CVE-2024-57924)
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:
media: uvcvideo: Fix double free in error path
If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it.
Reviewed by: Ricardo Ribalda <ribalda@chromium.org>(CVE-2024-57980)
In the Linux kernel, the following vulnerability has been resolved:
tpm: Change to kvalloc() in eventlog/acpi.c
The following failure was reported on HPE ProLiant D320:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action().(CVE-2024-58005)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: Add NULL check in mt_input_configured
devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error.(CVE-2024-58020)
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:
ASoC: soc-pcm: don't use soc_pcm_ret() on .prepare callback
commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port" log severity") ignores -EINVAL error message on common soc_pcm_ret(). It is used from many functions, ignoring -EINVAL is over-kill.
The reason why -EINVAL was ignored was it really should only be used upon invalid parameters coming from userspace and in that case we don't want to log an error since we do not want to give userspace a way to do a denial-of-service attack on the syslog / diskspace.
So don't use soc_pcm_ret() on .prepare callback is better idea.(CVE-2024-58077)
In the Linux kernel, the following vulnerability has been resolved:
misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors
misc_minor_alloc was allocating id using ida for minor only in case of MISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids using ida_free causing a mismatch and following warn: > > WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f > > ida_free called for id=127 which is not allocated. > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ... > > [<60941eb4>] ida_free+0x3e0/0x41f > > [<605ac993>] misc_minor_free+0x3e/0xbc > > [<605acb82>] misc_deregister+0x171/0x1b3
misc_minor_alloc is changed to allocate id from ida for all minors falling in the range of dynamic/ misc dynamic minors(CVE-2024-58078)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double free of TCP_Server_Info::hostname
When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen:
RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK>(CVE-2025-21673)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel
Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues: 1. In SA add section, the should be _bh() variant when marking SA mode. 2. There is not needed flush_workqueue in SA delete routine. It is not needed as at this stage as it is removed from SADB and the running work will be canceled later in SA free.
===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.12.0+ #4 Not tainted
charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]
and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 which would create a new lock dependency: (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3}
but this new dependency connects a SOFTIRQ-irq-safe lock: (&x->lock){+.-.}-{3:3}
... which became SOFTIRQ-irq-safe at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60 hrtimer_run_softirq+0x146/0x2e0 handle_softirqs+0x266/0x860 irq_exit_rcu+0x115/0x1a0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 default_idle+0x13/0x20 default_idle_call+0x67/0xa0 do_idle+0x2da/0x320 cpu_startup_entry+0x50/0x60 start_secondary+0x213/0x2a0 common_startup_64+0x129/0x138
to a SOFTIRQ-irq-unsafe lock: (&xa->xa_lock#24){+.+.}-{3:3}
... which became SOFTIRQ-irq-unsafe at: ... lock_acquire+0x1be/0x520 _raw_spin_lock+0x2c/0x40 xa_set_mark+0x70/0x110 mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core] xfrm_dev_state_add+0x3bb/0xd70 xfrm_add_sa+0x2451/0x4a90 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&xa->xa_lock#24); local_irq_disable(); lock(&x->lock); lock(&xa->xa_lock#24); <Interrupt> lock(&x->lock);
*** DEADLOCK ***
2 locks held by charon/1337: #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30
the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_alloc_spi+0xc0/0xe60 xfrm_alloc_userspi+0x5f6/0xbc0 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 IN-SOFTIRQ-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60
---truncated---(CVE-2025-21674)
In the Linux kernel, the following vulnerability has been resolved:
pktgen: Avoid out-of-bounds access in get_imix_entries
Passing a sufficient amount of imix entries leads to invalid access to the pkt_dev->imix_entries array because of the incorrect boundary check.
UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imix_pkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl lib/dump_stack.c:117 __ubsan_handle_out_of_bounds lib/ubsan.c:429 get_imix_entries net/core/pktgen.c:874 pktgen_if_write net/core/pktgen.c:1063 pde_write fs/proc/inode.c:334 proc_reg_write fs/proc/inode.c:346 vfs_write fs/read_write.c:593 ksys_write fs/read_write.c:644 do_syscall_64 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130
Found by Linux Verification Center (linuxtesting.org) with SVACE.
fp: allow to fill the array completely; minor changelog cleanup
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix lockup on tx to unregistering netdev with carrier
Commit in a fixes tag attempted to fix the issue in the following sequence of calls:
do_output
-> ovs_vport_send
-> dev_queue_xmit
-> __dev_queue_xmit
-> netdev_core_pick_tx
-> skb_tx_hash
When device is unregistering, the 'dev->real_num_tx_queues' goes to zero and the 'while (unlikely(hash >= qcount))' loop inside the 'skb_tx_hash' becomes infinite, locking up the core forever.
But unfortunately, checking just the carrier status is not enough to fix the issue, because some devices may still be in unregistering state while reporting carrier status OK.
One example of such device is a net/dummy. It sets carrier ON on start, but it doesn't implement .ndo_stop to set the carrier off. And it makes sense, because dummy doesn't really have a carrier. Therefore, while this device is unregistering, it's still easy to hit the infinite loop in the skb_tx_hash() from the OVS datapath. There might be other drivers that do the same, but dummy by itself is important for the OVS ecosystem, because it is frequently used as a packet sink for tcpdump while debugging OVS deployments. And when the issue is hit, the only way to recover is to reboot.
Fix that by also checking if the device is running. The running state is handled by the net core during unregistering, so it covers unregistering case better, and we don't really need to send packets to devices that are not running anyway.
While only checking the running state might be enough, the carrier check is preserved. The running and the carrier states seem disjoined throughout the code and different drivers. And other core functions like __dev_direct_xmit() check both before attempting to transmit a packet. So, it seems safer to check both flags in OVS as well.(CVE-2025-21681)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpf_sk_select_reuseport() memory leak
As pointed out in the original comment, lookup in sockmap can return a TCP ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb does not imply a non-refcounted socket.
Drop sk's reference in both error paths.
unreferenced object 0xffff888101911800 (size 2048): comm "test_progs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21683)
In the Linux kernel, the following vulnerability has been resolved:
cachestat: fix page cache statistics permission checking
When the 'cachestat()' system call was added in commit cf264e1329fb ("cachestat: implement cachestat syscall"), it was meant to be a much more convenient (and performant) version of mincore() that didn't need mapping things into the user virtual address space in order to work.
But it ended up missing the "check for writability or ownership" fix for mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore() more conservative").
This just adds equivalent logic to 'cachestat()', modified for the file context (rather than vma).(CVE-2025-21691)
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:
misc: fastrpc: Fix copy buffer page size
For non-registered buffer, fastrpc driver copies the buffer and pass it to the remote subsystem. There is a problem with current implementation of page size calculation which is not considering the offset in the calculation. This might lead to passing of improper and out-of-bounds page size which could result in memory issue. Calculate page start and page end using the offset adjusted address instead of absolute address.(CVE-2025-21734)
In the Linux kernel, the following vulnerability has been resolved:
ata: libata-sff: Ensure that we cannot write outside the allocated buffer
reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to write outside the allocated buffer, overwriting random memory.
While a ATA device is supposed to abort a ATA_NOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by ata_sff_hsm_move(). Anyway, that is most likely a separate bug.
Looking at __atapi_pio_bytes(), it already has a safety check to ensure that __atapi_pio_bytes() cannot write outside the allocated buffer.
Add a similar check to ata_pio_sector(), such that also ata_pio_sector() cannot write outside the allocated buffer.(CVE-2025-21738)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix assertion failure when splitting ordered extent after transaction abort
If while we are doing a direct IO write a transaction abort happens, we mark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done at btrfs_destroy_ordered_extents()), and then after that if we enter btrfs_split_ordered_extent() and the ordered extent has bytes left (meaning we have a bio that doesn't cover the whole ordered extent, see details at btrfs_extract_ordered_extent()), we will fail on the following assertion at btrfs_split_ordered_extent():
ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS));
because the BTRFS_ORDERED_IOERR flag is set and the definition of BTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the type of write (regular, nocow, prealloc, compressed, direct IO, encoded).
Fix this by returning an error from btrfs_extract_ordered_extent() if we find the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will be the error that resulted in the transaction abort or -EIO if no transaction abort happened.
This was recently reported by syzbot with the following trace:
FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 fail_dump lib/fault-inject.c:53 [inline] should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 should_failslab+0xac/0x100 mm/failslab.c:46 slab_pre_alloc_hook mm/slub.c:4072 [inline] slab_alloc_node mm/slub.c:4148 [inline] __do_kmalloc_node mm/slub.c:4297 [inline] __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 check_system_chunk fs/btrfs/block-group.c:4319 [inline] do_chunk_alloc fs/btrfs/block-group.c:3891 [inline] btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline] find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline] btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 fs/read_write.c:1050 do_pwritev fs/read_write.c:1146 [inline] __do_sys_pwritev2 fs/read_write.c:1204 [inline] __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 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:0x7f1281f85d29 RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 </TASK> BTRFS error (device loop0 state A): Transaction aborted (error -12) BTRFS: error (device loop0 state A ---truncated---(CVE-2025-21754)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Keep the binding until socket destruction
Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().
Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:
1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
2. transport->release() calls vsock_remove_bound() without checking if
sk was bound and moved to bound list (refcnt=1)
3. vsock_bind() assumes sk is in unbound list and before
__vsock_insert_bound(vsock_bound_sockets()) calls
__vsock_remove_bound() which does:
list_del_init(&vsk->bound_table); // nop
sock_put(&vsk->sk); // refcnt=0
BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Allocated by task 2057: 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 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 2057: 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 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21756)
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:
team: better TEAM_OPTION_TYPE_STRING validation
syzbot reported following splat [1]
Make sure user-provided data contains one nul byte.
[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 _syssendmsg+0x877/0xb60 net/socket.c:2573 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 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-2025-21787)
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:
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:
tty: xilinx_uartps: split sysrq handling
lockdep detects the following circular locking dependency:
CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()
The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock.
Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock.(CVE-2025-21820)
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:
block: don't revert iter for -EIOCBQUEUED
blkdev_read_iter() has a few odd checks, like gating the position and count adjustment on whether or not the result is bigger-than-or-equal to zero (where bigger than makes more sense), and not checking the return value of blkdev_direct_IO() before doing an iov_iter_revert(). The latter can lead to attempting to revert with a negative value, which when passed to iov_iter_revert() as an unsigned value will lead to throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.
Be sane and don't revert for -EIOCBQUEUED, like what is done in other spots.(CVE-2025-21832)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Add check for next_buffer in receive_encrypted_standard()
Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference.(CVE-2025-21844)
In the Linux kernel, the following vulnerability has been resolved:
acct: perform last write from workqueue
In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs.
Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk.
This api should stop to exist though.(CVE-2025-21846)
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: add release function for struct device
According to device_release() in /drivers/base/core.c, a device without a release function is a broken device and must be fixed.
The current code directly frees the device after calling device_add() without waiting for other kernel parts to release their references. Thus, a reference could still be held to a struct device, e.g., by sysfs, leading to potential use-after-free issues if a proper release function is not set.(CVE-2025-21856)
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:
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:
perf/core: Add RCU read lock protection to perf_iterate_ctx()
The perf_iterate_ctx() function performs RCU list traversal but currently lacks RCU read lock protection. This causes lockdep warnings when running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:
WARNING: suspicious RCU usage
kernel/events/core.c:8168 RCU-list traversed in non-reader section!!
Call Trace:
lockdep_rcu_suspicious
? perf_event_addr_filters_apply
perf_iterate_ctx
perf_event_exec
begin_new_exec
? load_elf_phdrs
load_elf_binary
? lock_acquire
? find_held_lock
? bprm_execve
bprm_execve
do_execveat_common.isra.0
__x64_sys_execve
do_syscall_64
entry_SYSCALL_64_after_hwframe
This protection was previously present but was removed in commit bd2756811766 ("perf: Rewrite core context handling"). Add back the necessary rcu_read_lock()/rcu_read_unlock() pair around perf_iterate_ctx() call in perf_event_exec().
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"perf-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-85.0.0.90.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-85.0.0.90.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"perf-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-85.0.0.90.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-85.0.0.90.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-85.0.0.90.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\nSUNRPC: make sure cache entry active before cache_show\n\nThe function `c_show` was called with protection from RCU. This only\nensures that `cp` will not be freed. Therefore, the reference count for\n`cp` can drop to zero, which will trigger a refcount use-after-free\nwarning when `cache_get` is called. To resolve this issue, use\n`cache_get_rcu` to ensure that `cp` remains active.\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 7 PID: 822 at lib/refcount.c:25\nrefcount_warn_saturate+0xb1/0x120\nCPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb1/0x120\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n c_show+0x2fc/0x380 [sunrpc]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n proc_reg_read+0xe1/0x140\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()\n\nUnder certain kernel configurations when building with Clang/LLVM, the\ncompiler does not generate a return or jump as the terminator\ninstruction for ip_vs_protocol_init(), triggering the following objtool\nwarning during build time:\n\n vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()\n\nAt runtime, this either causes an oops when trying to load the ipvs\nmodule or a boot-time panic if ipvs is built-in. This same issue has\nbeen reported by the Intel kernel test robot previously.\n\nDigging deeper into both LLVM and the kernel code reveals this to be a\nundefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer\nof 64 chars to store the registered protocol names and leaves it\nuninitialized after definition. The function calls strnlen() when\nconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE\nstrnlen() performs an extra step to check whether the last byte of the\ninput char buffer is a null character (commit 3009f891bb9f (\u0026quot;fortify:\nAllow strlen() and strnlen() to pass compile-time known lengths\u0026quot;)).\nThis, together with possibly other configurations, cause the following\nIR to be generated:\n\n define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section \u0026quot;.init.text\u0026quot; align 16 !kcfi_type !29 {\n %1 = alloca [64 x i8], align 16\n ...\n\n 14: ; preds = %11\n %15 = getelementptr inbounds i8, ptr %1, i64 63\n %16 = load i8, ptr %15, align 1\n %17 = tail call i1 @llvm.is.constant.i8(i8 %16)\n %18 = icmp eq i8 %16, 0\n %19 = select i1 %17, i1 %18, i1 false\n br i1 %19, label %20, label %23\n\n 20: ; preds = %14\n %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23\n ...\n\n 23: ; preds = %14, %11, %20\n %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24\n ...\n }\n\nThe above code calculates the address of the last char in the buffer\n(value %15) and then loads from it (value %16). Because the buffer is\nnever initialized, the LLVM GVN pass marks value %16 as undefined:\n\n %13 = getelementptr inbounds i8, ptr %1, i64 63\n br i1 undef, label %14, label %17\n\nThis gives later passes (SCCP, in particular) more DCE opportunities by\npropagating the undef value further, and eventually removes everything\nafter the load on the uninitialized stack location:\n\n define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section \u0026quot;.init.text\u0026quot; align 16 !kcfi_type !11 {\n %1 = alloca [64 x i8], align 16\n ...\n\n 12: ; preds = %11\n %13 = getelementptr inbounds i8, ptr %1, i64 63\n unreachable\n }\n\nIn this way, the generated native code will just fall through to the\nnext function, as LLVM does not generate any code for the unreachable IR\ninstruction and leaves the function without a terminator.\n\nZero the on-stack buffer to avoid this possible UB.(CVE-2024-53680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: avoid potential UAF in default_operstate()\n\nsyzbot reported an UAF in default_operstate() [1]\n\nIssue is a race between device and netns dismantles.\n\nAfter calling __rtnl_unlock() from netdev_run_todo(),\nwe can not assume the netns of each device is still alive.\n\nMake sure the device is not in NETREG_UNREGISTERED state,\nand add an ASSERT_RTNL() before the call to\n__dev_get_by_index().\n\nWe might move this ASSERT_RTNL() in __dev_get_by_index()\nin the future.\n\n[1]\n\nBUG: KASAN: slab-use-after-free in __dev_get_by_index+0x5d/0x110 net/core/dev.c:852\nRead of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339\n\nCPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n __dev_get_by_index+0x5d/0x110 net/core/dev.c:852\n default_operstate net/core/link_watch.c:51 [inline]\n rfc2863_policy+0x224/0x300 net/core/link_watch.c:67\n linkwatch_do_dev+0x3e/0x170 net/core/link_watch.c:170\n netdev_run_todo+0x461/0x1000 net/core/dev.c:10894\n rtnl_unlock net/core/rtnetlink.c:152 [inline]\n rtnl_net_unlock include/linux/rtnetlink.h:133 [inline]\n rtnl_dellink+0x760/0x8d0 net/core/rtnetlink.c:3520\n rtnetlink_rcv_msg+0x791/0xcf0 net/core/rtnetlink.c:6911\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2541\n netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347\n netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x221/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\nRIP: 0033:0x7f2a3cb80809\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809\nRDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008\nRBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5339:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314\n kmalloc_noprof include/linux/slab.h:901 [inline]\n kmalloc_array_noprof include/linux/slab.h:945 [inline]\n netdev_create_hash net/core/dev.c:11870 [inline]\n netdev_init+0x10c/0x250 net/core/dev.c:11890\n ops_init+0x31e/0x590 net/core/net_namespace.c:138\n setup_net+0x287/0x9e0 net/core/net_namespace.c:362\n copy_net_ns+0x33f/0x570 net/core/net_namespace.c:500\n create_new_namespaces+0x425/0x7b0 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0x124/0x180 kernel/nsproxy.c:228\n ksys_unshare+0x57d/0xa70 kernel/fork.c:3314\n __do_sys_unshare kernel/fork.c:3385 [inline]\n __se_sys_unshare kernel/fork.c:3383 [inline]\n __x64_sys_unshare+0x38/0x40 kernel/fork.c:3383\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x8\n---truncated---(CVE-2024-56635)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix recursive lock when verdict program return SK_PASS\n\nWhen the stream_verdict program returns SK_PASS, it places the received skb\ninto its own receive queue, but a recursive lock eventually occurs, leading\nto an operating system deadlock. This issue has been present since v6.9.\n\n\u0026apos;\u0026apos;\u0026apos;\nsk_psock_strp_data_ready\n write_lock_bh(\u0026amp;sk-\u0026gt;sk_callback_lock)\n strp_data_ready\n strp_read_sock\n read_sock -\u0026gt; tcp_read_sock\n strp_recv\n cb.rcv_msg -\u0026gt; sk_psock_strp_read\n # now stream_verdict return SK_PASS without peer sock assign\n __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)\n sk_psock_verdict_apply\n sk_psock_skb_ingress_self\n sk_psock_skb_ingress_enqueue\n sk_psock_data_ready\n read_lock_bh(\u0026amp;sk-\u0026gt;sk_callback_lock) \u0026lt;= dead lock\n\n\u0026apos;\u0026apos;\u0026apos;\n\nThis topic has been discussed before, but it has not been fixed.\nPrevious discussion:\nhttps://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch(CVE-2024-56694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: relax assertions on failure to encode file handles\n\nEncoding file handles is usually performed by a filesystem \u0026gt;encode_fh()\nmethod that may fail for various reasons.\n\nThe legacy users of exportfs_encode_fh(), namely, nfsd and\nname_to_handle_at(2) syscall are ready to cope with the possibility\nof failure to encode a file handle.\n\nThere are a few other users of exportfs_encode_{fh,fid}() that\ncurrently have a WARN_ON() assertion when -\u0026gt;encode_fh() fails.\nRelax those assertions because they are wrong.\n\nThe second linked bug report states commit 16aac5ad1fa9 (\u0026quot;ovl: support\nencoding non-decodable file handles\u0026quot;) in v6.6 as the regressing commit,\nbut this is not accurate.\n\nThe aforementioned commit only increases the chances of the assertion\nand allows triggering the assertion with the reproducer using overlayfs,\ninotify and drop_caches.\n\nTriggering this assertion was always possible with other filesystems and\nother reasons of -\u0026gt;encode_fh() failures and more particularly, it was\nalso possible with the exact same reproducer using overlayfs that is\nmounted with options index=on,nfs_export=on also on kernels \u0026lt; v6.6.\nTherefore, I am not listing the aforementioned commit as a Fixes commit.\n\nBackport hint: this patch will have a trivial conflict applying to\nv6.6.y, and other trivial conflicts applying to stable kernels \u0026lt; v6.6.(CVE-2024-57924)\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\nmedia: uvcvideo: Fix double free in error path\n\nIf the uvc_status_init() function fails to allocate the int_urb, it will\nfree the dev-\u0026gt;status pointer but doesn\u0026apos;t reset the pointer to NULL. This\nresults in the kfree() call in uvc_status_cleanup() trying to\ndouble-free the memory. Fix it by resetting the dev-\u0026gt;status pointer to\nNULL after freeing it.\n\nReviewed by: Ricardo Ribalda \u0026lt;ribalda@chromium.org\u0026gt;(CVE-2024-57980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Change to kvalloc() in eventlog/acpi.c\n\nThe following failure was reported on HPE ProLiant D320:\n\n[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)\n[ 10.848132][ T1] ------------[ cut here ]------------\n[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330\n[ 10.862827][ T1] Modules linked in:\n[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375\n[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024\n[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330\n[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 \u0026lt;0f\u0026gt; 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1\n[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246\n[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000\n[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0\n\nThe above transcript shows that ACPI pointed a 16 MiB buffer for the log\nevents because RSI maps to the \u0026apos;order\u0026apos; parameter of __alloc_pages_noprof().\nAddress the bug by moving from devm_kmalloc() to devm_add_action() and\nkvmalloc() and devm_add_action().(CVE-2024-58005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Add NULL check in mt_input_configured\n\ndevm_kasprintf() can return a NULL pointer on failure,but this\nreturned value in mt_input_configured() is not checked.\nAdd NULL check in mt_input_configured(), to handle kernel NULL\npointer dereference error.(CVE-2024-58020)\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\nASoC: soc-pcm: don\u0026apos;t use soc_pcm_ret() on .prepare callback\n\ncommit 1f5664351410 (\u0026quot;ASoC: lower \u0026quot;no backend DAIs enabled for ... Port\u0026quot;\nlog severity\u0026quot;) ignores -EINVAL error message on common soc_pcm_ret().\nIt is used from many functions, ignoring -EINVAL is over-kill.\n\nThe reason why -EINVAL was ignored was it really should only be used\nupon invalid parameters coming from userspace and in that case we don\u0026apos;t\nwant to log an error since we do not want to give userspace a way to do\na denial-of-service attack on the syslog / diskspace.\n\nSo don\u0026apos;t use soc_pcm_ret() on .prepare callback is better idea.(CVE-2024-58077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors\n\nmisc_minor_alloc was allocating id using ida for minor only in case of\nMISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids\nusing ida_free causing a mismatch and following warn:\n\u0026gt; \u0026gt; WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f\n\u0026gt; \u0026gt; ida_free called for id=127 which is not allocated.\n\u0026gt; \u0026gt; \u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt;\n...\n\u0026gt; \u0026gt; [\u0026lt;60941eb4\u0026gt;] ida_free+0x3e0/0x41f\n\u0026gt; \u0026gt; [\u0026lt;605ac993\u0026gt;] misc_minor_free+0x3e/0xbc\n\u0026gt; \u0026gt; [\u0026lt;605acb82\u0026gt;] misc_deregister+0x171/0x1b3\n\nmisc_minor_alloc is changed to allocate id from ida for all minors\nfalling in the range of dynamic/ misc dynamic minors(CVE-2024-58078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix double free of TCP_Server_Info::hostname\n\nWhen shutting down the server in cifs_put_tcp_session(), cifsd thread\nmight be reconnecting to multiple DFS targets before it realizes it\nshould exit the loop, so @server-\u0026gt;hostname can\u0026apos;t be freed as long as\ncifsd thread isn\u0026apos;t done. Otherwise the following can happen:\n\n RIP: 0010:__slab_free+0x223/0x3c0\n Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89\n 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff \u0026lt;0f\u0026gt;\n 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80\n RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246\n RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068\n RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400\n RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000\n R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500\n R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068\n FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000)\n 000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4:\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? show_trace_log_lvl+0x1c4/0x2df\n ? show_trace_log_lvl+0x1c4/0x2df\n ? __reconnect_target_unlocked+0x3e/0x160 [cifs]\n ? __die_body.cold+0x8/0xd\n ? die+0x2b/0x50\n ? do_trap+0xce/0x120\n ? __slab_free+0x223/0x3c0\n ? do_error_trap+0x65/0x80\n ? __slab_free+0x223/0x3c0\n ? exc_invalid_op+0x4e/0x70\n ? __slab_free+0x223/0x3c0\n ? asm_exc_invalid_op+0x16/0x20\n ? __slab_free+0x223/0x3c0\n ? extract_hostname+0x5c/0xa0 [cifs]\n ? extract_hostname+0x5c/0xa0 [cifs]\n ? __kmalloc+0x4b/0x140\n __reconnect_target_unlocked+0x3e/0x160 [cifs]\n reconnect_dfs_server+0x145/0x430 [cifs]\n cifs_handle_standard+0x1ad/0x1d0 [cifs]\n cifs_demultiplex_thread+0x592/0x730 [cifs]\n ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]\n kthread+0xdd/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x29/0x50\n \u0026lt;/TASK\u0026gt;(CVE-2025-21673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel\n\nAttempt to enable IPsec packet offload in tunnel mode in debug kernel\ngenerates the following kernel panic, which is happening due to two\nissues:\n1. In SA add section, the should be _bh() variant when marking SA mode.\n2. There is not needed flush_workqueue in SA delete routine. It is not\nneeded as at this stage as it is removed from SADB and the running work\nwill be canceled later in SA free.\n\n =====================================================\n WARNING: SOFTIRQ-safe -\u0026gt; SOFTIRQ-unsafe lock order detected\n 6.12.0+ #4 Not tainted\n -----------------------------------------------------\n charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:\n ffff88810f365020 (\u0026amp;xa-\u0026gt;xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]\n\n and this task is already holding:\n ffff88813e0f0d48 (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n which would create a new lock dependency:\n (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3} -\u0026gt; (\u0026amp;xa-\u0026gt;xa_lock#24){+.+.}-{3:3}\n\n but this new dependency connects a SOFTIRQ-irq-safe lock:\n (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3}\n\n ... which became SOFTIRQ-irq-safe at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_timer_handler+0x91/0xd70\n __hrtimer_run_queues+0x1dd/0xa60\n hrtimer_run_softirq+0x146/0x2e0\n handle_softirqs+0x266/0x860\n irq_exit_rcu+0x115/0x1a0\n sysvec_apic_timer_interrupt+0x6e/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n default_idle+0x13/0x20\n default_idle_call+0x67/0xa0\n do_idle+0x2da/0x320\n cpu_startup_entry+0x50/0x60\n start_secondary+0x213/0x2a0\n common_startup_64+0x129/0x138\n\n to a SOFTIRQ-irq-unsafe lock:\n (\u0026amp;xa-\u0026gt;xa_lock#24){+.+.}-{3:3}\n\n ... which became SOFTIRQ-irq-unsafe at:\n ...\n lock_acquire+0x1be/0x520\n _raw_spin_lock+0x2c/0x40\n xa_set_mark+0x70/0x110\n mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]\n xfrm_dev_state_add+0x3bb/0xd70\n xfrm_add_sa+0x2451/0x4a90\n xfrm_user_rcv_msg+0x493/0x880\n netlink_rcv_skb+0x12e/0x380\n xfrm_netlink_rcv+0x6d/0x90\n netlink_unicast+0x42f/0x740\n netlink_sendmsg+0x745/0xbe0\n __sock_sendmsg+0xc5/0x190\n __sys_sendto+0x1fe/0x2c0\n __x64_sys_sendto+0xdc/0x1b0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n other info that might help us debug this:\n\n Possible interrupt unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026amp;xa-\u0026gt;xa_lock#24);\n local_irq_disable();\n lock(\u0026amp;x-\u0026gt;lock);\n lock(\u0026amp;xa-\u0026gt;xa_lock#24);\n \u0026lt;Interrupt\u0026gt;\n lock(\u0026amp;x-\u0026gt;lock);\n\n *** DEADLOCK ***\n\n 2 locks held by charon/1337:\n #0: ffffffff87f8f858 (\u0026amp;net-\u0026gt;xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90\n #1: ffff88813e0f0d48 (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30\n\n the dependencies between SOFTIRQ-irq-safe lock and the holding lock:\n -\u0026gt; (\u0026amp;x-\u0026gt;lock){+.-.}-{3:3} ops: 29 {\n HARDIRQ-ON-W at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_alloc_spi+0xc0/0xe60\n xfrm_alloc_userspi+0x5f6/0xbc0\n xfrm_user_rcv_msg+0x493/0x880\n netlink_rcv_skb+0x12e/0x380\n xfrm_netlink_rcv+0x6d/0x90\n netlink_unicast+0x42f/0x740\n netlink_sendmsg+0x745/0xbe0\n __sock_sendmsg+0xc5/0x190\n __sys_sendto+0x1fe/0x2c0\n __x64_sys_sendto+0xdc/0x1b0\n do_syscall_64+0x6d/0x140\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n IN-SOFTIRQ-W at:\n lock_acquire+0x1be/0x520\n _raw_spin_lock_bh+0x34/0x40\n xfrm_timer_handler+0x91/0xd70\n __hrtimer_run_queues+0x1dd/0xa60\n \n---truncated---(CVE-2025-21674)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npktgen: Avoid out-of-bounds access in get_imix_entries\n\nPassing a sufficient amount of imix entries leads to invalid access to the\npkt_dev-\u0026gt;imix_entries array because of the incorrect boundary check.\n\nUBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24\nindex 20 is out of range for type \u0026apos;imix_pkt [20]\u0026apos;\nCPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl lib/dump_stack.c:117\n__ubsan_handle_out_of_bounds lib/ubsan.c:429\nget_imix_entries net/core/pktgen.c:874\npktgen_if_write net/core/pktgen.c:1063\npde_write fs/proc/inode.c:334\nproc_reg_write fs/proc/inode.c:346\nvfs_write fs/read_write.c:593\nksys_write fs/read_write.c:644\ndo_syscall_64 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[ fp: allow to fill the array completely; minor changelog cleanup ](CVE-2025-21680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix lockup on tx to unregistering netdev with carrier\n\nCommit in a fixes tag attempted to fix the issue in the following\nsequence of calls:\n\n do_output\n -\u0026gt; ovs_vport_send\n -\u0026gt; dev_queue_xmit\n -\u0026gt; __dev_queue_xmit\n -\u0026gt; netdev_core_pick_tx\n -\u0026gt; skb_tx_hash\n\nWhen device is unregistering, the \u0026apos;dev-\u0026gt;real_num_tx_queues\u0026apos; goes to\nzero and the \u0026apos;while (unlikely(hash \u0026gt;= qcount))\u0026apos; loop inside the\n\u0026apos;skb_tx_hash\u0026apos; becomes infinite, locking up the core forever.\n\nBut unfortunately, checking just the carrier status is not enough to\nfix the issue, because some devices may still be in unregistering\nstate while reporting carrier status OK.\n\nOne example of such device is a net/dummy. It sets carrier ON\non start, but it doesn\u0026apos;t implement .ndo_stop to set the carrier off.\nAnd it makes sense, because dummy doesn\u0026apos;t really have a carrier.\nTherefore, while this device is unregistering, it\u0026apos;s still easy to hit\nthe infinite loop in the skb_tx_hash() from the OVS datapath. There\nmight be other drivers that do the same, but dummy by itself is\nimportant for the OVS ecosystem, because it is frequently used as a\npacket sink for tcpdump while debugging OVS deployments. And when the\nissue is hit, the only way to recover is to reboot.\n\nFix that by also checking if the device is running. The running\nstate is handled by the net core during unregistering, so it covers\nunregistering case better, and we don\u0026apos;t really need to send packets\nto devices that are not running anyway.\n\nWhile only checking the running state might be enough, the carrier\ncheck is preserved. The running and the carrier states seem disjoined\nthroughout the code and different drivers. And other core functions\nlike __dev_direct_xmit() check both before attempting to transmit\na packet. So, it seems safer to check both flags in OVS as well.(CVE-2025-21681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix bpf_sk_select_reuseport() memory leak\n\nAs pointed out in the original comment, lookup in sockmap can return a TCP\nESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF\nset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb\ndoes not imply a non-refcounted socket.\n\nDrop sk\u0026apos;s reference in both error paths.\n\nunreferenced object 0xffff888101911800 (size 2048):\n comm \u0026quot;test_progs\u0026quot;, pid 44109, jiffies 4297131437\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 9336483b):\n __kmalloc_noprof+0x3bf/0x560\n __reuseport_alloc+0x1d/0x40\n reuseport_alloc+0xca/0x150\n reuseport_attach_prog+0x87/0x140\n sk_reuseport_attach_bpf+0xc8/0x100\n sk_setsockopt+0x1181/0x1990\n do_sock_setsockopt+0x12b/0x160\n __sys_setsockopt+0x7b/0xc0\n __x64_sys_setsockopt+0x1b/0x30\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncachestat: fix page cache statistics permission checking\n\nWhen the \u0026apos;cachestat()\u0026apos; system call was added in commit cf264e1329fb\n(\u0026quot;cachestat: implement cachestat syscall\u0026quot;), it was meant to be a much\nmore convenient (and performant) version of mincore() that didn\u0026apos;t need\nmapping things into the user virtual address space in order to work.\n\nBut it ended up missing the \u0026quot;check for writability or ownership\u0026quot; fix for\nmincore(), done in commit 134fca9063ad (\u0026quot;mm/mincore.c: make mincore()\nmore conservative\u0026quot;).\n\nThis just adds equivalent logic to \u0026apos;cachestat()\u0026apos;, modified for the file\ncontext (rather than vma).(CVE-2025-21691)\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\nmisc: fastrpc: Fix copy buffer page size\n\nFor non-registered buffer, fastrpc driver copies the buffer and\npass it to the remote subsystem. There is a problem with current\nimplementation of page size calculation which is not considering\nthe offset in the calculation. This might lead to passing of\nimproper and out-of-bounds page size which could result in\nmemory issue. Calculate page start and page end using the offset\nadjusted address instead of absolute address.(CVE-2025-21734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-sff: Ensure that we cannot write outside the allocated buffer\n\nreveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len\nset to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to\nATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to\nwrite outside the allocated buffer, overwriting random memory.\n\nWhile a ATA device is supposed to abort a ATA_NOP command, there does seem\nto be a bug either in libata-sff or QEMU, where either this status is not\nset, or the status is cleared before read by ata_sff_hsm_move().\nAnyway, that is most likely a separate bug.\n\nLooking at __atapi_pio_bytes(), it already has a safety check to ensure\nthat __atapi_pio_bytes() cannot write outside the allocated buffer.\n\nAdd a similar check to ata_pio_sector(), such that also ata_pio_sector()\ncannot write outside the allocated buffer.(CVE-2025-21738)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix assertion failure when splitting ordered extent after transaction abort\n\nIf while we are doing a direct IO write a transaction abort happens, we\nmark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done\nat btrfs_destroy_ordered_extents()), and then after that if we enter\nbtrfs_split_ordered_extent() and the ordered extent has bytes left\n(meaning we have a bio that doesn\u0026apos;t cover the whole ordered extent, see\ndetails at btrfs_extract_ordered_extent()), we will fail on the following\nassertion at btrfs_split_ordered_extent():\n\n ASSERT(!(flags \u0026amp; ~BTRFS_ORDERED_TYPE_FLAGS));\n\nbecause the BTRFS_ORDERED_IOERR flag is set and the definition of\nBTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the\ntype of write (regular, nocow, prealloc, compressed, direct IO, encoded).\n\nFix this by returning an error from btrfs_extract_ordered_extent() if we\nfind the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will\nbe the error that resulted in the transaction abort or -EIO if no\ntransaction abort happened.\n\nThis was recently reported by syzbot with the following trace:\n\n FAULT_INJECTION: forcing a failure.\n name failslab, interval 1, probability 0, space 0, times 1\n CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n Call 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 fail_dump lib/fault-inject.c:53 [inline]\n should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154\n should_failslab+0xac/0x100 mm/failslab.c:46\n slab_pre_alloc_hook mm/slub.c:4072 [inline]\n slab_alloc_node mm/slub.c:4148 [inline]\n __do_kmalloc_node mm/slub.c:4297 [inline]\n __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1037 [inline]\n btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742\n reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292\n check_system_chunk fs/btrfs/block-group.c:4319 [inline]\n do_chunk_alloc fs/btrfs/block-group.c:3891 [inline]\n btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187\n find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline]\n find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579\n btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672\n btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline]\n btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321\n btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525\n iomap_iter+0x697/0xf60 fs/iomap/iter.c:90\n __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702\n btrfs_dio_write fs/btrfs/direct-io.c:775 [inline]\n btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880\n btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397\n do_iter_readv_writev+0x600/0x880\n vfs_writev+0x376/0xba0 fs/read_write.c:1050\n do_pwritev fs/read_write.c:1146 [inline]\n __do_sys_pwritev2 fs/read_write.c:1204 [inline]\n __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195\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:0x7f1281f85d29\n RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148\n RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29\n RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005\n RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003\n R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002\n R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328\n \u0026lt;/TASK\u0026gt;\n BTRFS error (device loop0 state A): Transaction aborted (error -12)\n BTRFS: error (device loop0 state A\n---truncated---(CVE-2025-21754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Keep the binding until socket destruction\n\nPreserve sockets bindings; this includes both resulting from an explicit\nbind() and those implicitly bound through autobind during connect().\n\nPrevents socket unbinding during a transport reassignment, which fixes a\nuse-after-free:\n\n 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)\n 2. transport-\u0026gt;release() calls vsock_remove_bound() without checking if\n sk was bound and moved to bound list (refcnt=1)\n 3. vsock_bind() assumes sk is in unbound list and before\n __vsock_insert_bound(vsock_bound_sockets()) calls\n __vsock_remove_bound() which does:\n list_del_init(\u0026amp;vsk-\u0026gt;bound_table); // nop\n sock_put(\u0026amp;vsk-\u0026gt;sk); // refcnt=0\n\nBUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730\nRead of size 4 at addr ffff88816b46a74c by task a.out/2057\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n __vsock_bind+0x62e/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nAllocated by task 2057:\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 __vsock_create.constprop.0+0x2e/0xb60\n vsock_create+0xe4/0x420\n __sock_create+0x241/0x650\n __sys_socket+0xf2/0x1a0\n __x64_sys_socket+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 2057:\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 __vsock_bind+0x5e1/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150\nRIP: 0010:refcount_warn_saturate+0xce/0x150\n __vsock_bind+0x66d/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150\nRIP: 0010:refcount_warn_saturate+0xee/0x150\n vsock_remove_bound+0x187/0x1e0\n __vsock_release+0x383/0x4a0\n vsock_release+0x90/0x120\n __sock_release+0xa3/0x250\n sock_close+0x14/0x20\n __fput+0x359/0xa80\n task_work_run+0x107/0x1d0\n do_exit+0x847/0x2560\n do_group_exit+0xb8/0x250\n __x64_sys_exit_group+0x3a/0x50\n x64_sys_call+0xfec/0x14f0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21756)\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\nteam: better TEAM_OPTION_TYPE_STRING validation\n\nsyzbot reported following splat [1]\n\nMake sure user-provided data contains one nul byte.\n\n[1]\n BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline]\n BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714\n string_nocheck lib/vsprintf.c:633 [inline]\n string+0x3ec/0x5f0 lib/vsprintf.c:714\n vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843\n __request_module+0x252/0x9f0 kernel/module/kmod.c:149\n team_mode_get drivers/net/team/team_core.c:480 [inline]\n team_change_mode drivers/net/team/team_core.c:607 [inline]\n team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401\n team_option_set drivers/net/team/team_core.c:375 [inline]\n team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662\n genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543\n genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]\n netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348\n netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892\n sock_sendmsg_nosec net/socket.c:718 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:733\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2573\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627\n __sys_sendmsg net/socket.c:2659 [inline]\n __do_sys_sendmsg net/socket.c:2664 [inline]\n __se_sys_sendmsg net/socket.c:2662 [inline]\n __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662\n x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47\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-2025-21787)\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\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\ntty: xilinx_uartps: split sysrq handling\n\nlockdep detects the following circular locking dependency:\n\nCPU 0 CPU 1\n========================== ============================\ncdns_uart_isr() printk()\n uart_port_lock(port) console_lock()\n\t\t\t cdns_uart_console_write()\n if (!port-\u0026gt;sysrq)\n uart_port_lock(port)\n uart_handle_break()\n port-\u0026gt;sysrq = ...\n uart_handle_sysrq_char()\n printk()\n console_lock()\n\nThe fixed commit attempts to avoid this situation by only taking the\nport lock in cdns_uart_console_write if port-\u0026gt;sysrq unset. However, if\n(as shown above) cdns_uart_console_write runs before port-\u0026gt;sysrq is set,\nthen it will try to take the port lock anyway. This may result in a\ndeadlock.\n\nFix this by splitting sysrq handling into two parts. We use the prepare\nhelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)\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\nblock: don\u0026apos;t revert iter for -EIOCBQUEUED\n\nblkdev_read_iter() has a few odd checks, like gating the position and\ncount adjustment on whether or not the result is bigger-than-or-equal to\nzero (where bigger than makes more sense), and not checking the return\nvalue of blkdev_direct_IO() before doing an iov_iter_revert(). The\nlatter can lead to attempting to revert with a negative value, which\nwhen passed to iov_iter_revert() as an unsigned value will lead to\nthrowing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.\n\nBe sane and don\u0026apos;t revert for -EIOCBQUEUED, like what is done in other\nspots.(CVE-2025-21832)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Add check for next_buffer in receive_encrypted_standard()\n\nAdd check for the return value of cifs_buf_get() and cifs_small_buf_get()\nin receive_encrypted_standard() to prevent null pointer dereference.(CVE-2025-21844)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nacct: perform last write from workqueue\n\nIn [1] it was reported that the acct(2) system call can be used to\ntrigger NULL deref in cases where it is set to write to a file that\ntriggers an internal lookup. This can e.g., happen when pointing acc(2)\nto /sys/power/resume. At the point the where the write to this file\nhappens the calling task has already exited and called exit_fs(). A\nlookup will thus trigger a NULL-deref when accessing current-\u0026gt;fs.\n\nReorganize the code so that the the final write happens from the\nworkqueue but with the caller\u0026apos;s credentials. This preserves the\n(strange) permission model and has almost no regression risk.\n\nThis api should stop to exist though.(CVE-2025-21846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/ism: add release function for struct device\n\nAccording to device_release() in /drivers/base/core.c,\na device without a release function is a broken device\nand must be fixed.\n\nThe current code directly frees the device after calling device_add()\nwithout waiting for other kernel parts to release their references.\nThus, a reference could still be held to a struct device,\ne.g., by sysfs, leading to potential use-after-free\nissues if a proper release function is not set.(CVE-2025-21856)\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\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\nperf/core: Add RCU read lock protection to perf_iterate_ctx()\n\nThe perf_iterate_ctx() function performs RCU list traversal but\ncurrently lacks RCU read lock protection. This causes lockdep warnings\nwhen running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:\n\n\tWARNING: suspicious RCU usage\n\tkernel/events/core.c:8168 RCU-list traversed in non-reader section!!\n\n\t Call Trace:\n\t lockdep_rcu_suspicious\n\t ? perf_event_addr_filters_apply\n\t perf_iterate_ctx\n\t perf_event_exec\n\t begin_new_exec\n\t ? load_elf_phdrs\n\t load_elf_binary\n\t ? lock_acquire\n\t ? find_held_lock\n\t ? bprm_execve\n\t bprm_execve\n\t do_execveat_common.isra.0\n\t __x64_sys_execve\n\t do_syscall_64\n\t entry_SYSCALL_64_after_hwframe\n\nThis protection was previously present but was removed in commit\nbd2756811766 (\u0026quot;perf: Rewrite core context handling\u0026quot;). Add back the\nnecessary rcu_read_lock()/rcu_read_unlock() pair around\nperf_iterate_ctx() call in perf_event_exec().\n\n[ mingo: Use scoped_guard() as suggested by Peter ](CVE-2025-21889)",
"id": "OESA-2025-1372",
"modified": "2026-08-06T11:08:28Z",
"published": "2025-04-03T11:08:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1372"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53174"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56694"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58055"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58077"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21674"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21680"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21681"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21691"
},
{
"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-21734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21754"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21787"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21791"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21816"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21820"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21856"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21889"
}
],
"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-53174",
"CVE-2024-53680",
"CVE-2024-56635",
"CVE-2024-56694",
"CVE-2024-57924",
"CVE-2024-57951",
"CVE-2024-57980",
"CVE-2024-58005",
"CVE-2024-58020",
"CVE-2024-58055",
"CVE-2024-58077",
"CVE-2024-58078",
"CVE-2025-21673",
"CVE-2025-21674",
"CVE-2025-21680",
"CVE-2025-21681",
"CVE-2025-21683",
"CVE-2025-21691",
"CVE-2025-21718",
"CVE-2025-21722",
"CVE-2025-21734",
"CVE-2025-21738",
"CVE-2025-21754",
"CVE-2025-21756",
"CVE-2025-21785",
"CVE-2025-21787",
"CVE-2025-21791",
"CVE-2025-21816",
"CVE-2025-21820",
"CVE-2025-21823",
"CVE-2025-21832",
"CVE-2025-21844",
"CVE-2025-21846",
"CVE-2025-21856",
"CVE-2025-21863",
"CVE-2025-21887",
"CVE-2025-21889"
]
}
OESA-2025-1409 (CVE-2021-47660)
Vulnerability from osv_openeuler – Published: 2025-04-11 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
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 (CVE-2021-47660)
Vulnerability from osv_openeuler – Published: 2025-04-11 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
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"
]
}
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.