Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-40170 (GCVE-0-2025-40170)
Vulnerability from cvelistv5 – Published: 2025-11-12 10:46 – Updated: 2026-08-05 12:08| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36 , < 5d1be493d1110c9e720b4c51a6e587bb2fb4ac12
(git)
Affected: 4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36 , < a805729c0091073d8f0415cfa96c7acd1bc17a48 (git) Affected: 4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36 , < 99a2ace61b211b0be861b07fbaa062fca4b58879 (git) |
guessed | |
| Linux | Linux |
Affected:
4.13
Unaffected: 0 , < 4.13 (semver) Unaffected: 6.12.64 , ≤ 6.12.* (semver) Unaffected: 6.17.3 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-40170",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T19:33:10.426175Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-16T19:33:20.303Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/ip.h",
"include/net/ip6_route.h",
"include/net/route.h",
"net/core/sock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5d1be493d1110c9e720b4c51a6e587bb2fb4ac12",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
},
{
"lessThan": "a805729c0091073d8f0415cfa96c7acd1bc17a48",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
},
{
"lessThan": "99a2ace61b211b0be861b07fbaa062fca4b58879",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/ip.h",
"include/net/ip6_route.h",
"include/net/route.h",
"net/core/sock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.13"
},
{
"lessThan": "4.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "4.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.3",
"versionStartIncluding": "4.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "4.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u003edev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu()."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The unprotected `sk_setup_caps()` reader is reached from process-context syscalls (connect/sendmsg/SCTP output), and the racing `dst_dev_put()`/netdev-unregister side requires local netns and link/route manipulation; the remote-triggered call site (`tcp_v4_syn_recv_sock`) runs BH-disabled and is implicitly RCU-protected.\nAC:L - The attacker controls both sides of the race \u2014 one thread loops connect()/sendmsg() on sockets holding the dst while another deletes the veth/route in its own netns \u2014 and can retry indefinitely until the window is hit.\nPR:L - An unprivileged local account suffices; CAP_NET_ADMIN needed for link/route teardown is obtainable without real root via user namespaces (`unshare -Urn`), and the socket side needs no privilege at all.\nUI:N - Exploitation is entirely driven by the attacker\u0027s own threads issuing socket syscalls and netlink link/route operations; no victim action is required.\nS:U - The use-after-free is on a kernel `struct net_device` and its effects stay within the kernel\u0027s own security authority, with no crossing of a VM, IOMMU, or sandbox boundary.\nC:H - This is a use-after-free read of a freed, heap-sprayable `net_device`; its contents are loaded into `sk_route_caps`, `sk_gso_max_size` and `sk_gso_max_segs`, which observably alter TCP segmentation and thus leak freed-memory contents, and per UAF guidance this is High.\nI:H - Values read from freed memory are written into persistent socket state and then drive packet construction \u2014 bogus SG/HW_CSUM/GSO feature bits and an underflowed multi-gigabyte `sk_gso_max_size` corrupt the TX path, and a UAF on a sprayable object is treatable as an arbitrary-write primitive.\nA:H - Dereferencing a freed `net_device` can oops outright, and the resulting garbage GSO sizes/segment counts produce oversized skb allocations and inconsistent offload state that crash the transmit path and drivers."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:08:15.716Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5d1be493d1110c9e720b4c51a6e587bb2fb4ac12"
},
{
"url": "https://git.kernel.org/stable/c/a805729c0091073d8f0415cfa96c7acd1bc17a48"
},
{
"url": "https://git.kernel.org/stable/c/99a2ace61b211b0be861b07fbaa062fca4b58879"
}
],
"title": "net: use dst_dev_rcu() in sk_setup_caps()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-40170",
"datePublished": "2025-11-12T10:46:52.014Z",
"dateReserved": "2025-04-16T07:20:57.176Z",
"dateUpdated": "2026-08-05T12:08:15.716Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-40170",
"date": "2026-10-09",
"epss": "0.00147",
"percentile": "0.03456"
},
"microsoft_vex": {
"current_release_date": "2026-09-23T02:31:58.000Z",
"cve": "CVE-2025-40170",
"id": "msrc_CVE-2025-40170",
"initial_release_date": "2025-11-13T01:02:57.000Z",
"product_status:known_affected": "17",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "net: use dst_dev_rcu() in sk_setup_caps()",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-40170.json",
"version": "18"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/ip.h",
"include/net/ip6_route.h",
"include/net/route.h",
"net/core/sock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5d1be493d1110c9e720b4c51a6e587bb2fb4ac12",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
},
{
"lessThan": "a805729c0091073d8f0415cfa96c7acd1bc17a48",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
},
{
"lessThan": "99a2ace61b211b0be861b07fbaa062fca4b58879",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/ip.h",
"include/net/ip6_route.h",
"include/net/route.h",
"net/core/sock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.13"
},
{
"lessThan": "4.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u003edev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu()."
}
],
"id": "CVE-2025-40170",
"lastModified": "2026-07-30T06:24:15.463",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-40170",
"options": [
{
"exploitation": "none"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T19:33:10.426175Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-11-12T11:15:47.393",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5d1be493d1110c9e720b4c51a6e587bb2fb4ac12"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/99a2ace61b211b0be861b07fbaa062fca4b58879"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a805729c0091073d8f0415cfa96c7acd1bc17a48"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-07-30T08:48:29+00:00",
"cve": "CVE-2025-40170",
"id": "CVE-2025-40170",
"initial_release_date": "2025-11-12T00:00:00+00:00",
"product_status:fixed": "1980",
"product_status:known_affected": "36",
"product_status:known_not_affected": "28",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: net: use dst_dev_rcu() in sk_setup_caps()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-40170.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-10-01T01:39:06Z",
"cve": "CVE-2025-40170",
"id": "CVE-2025-40170",
"initial_release_date": "2025-11-14T00:24:25Z",
"product_status:known_affected": "737",
"product_status:known_not_affected": "36",
"product_status:recommended": "510",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2025-40170",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-40170.json",
"version": "54"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-40170",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-06-16T19:33:10.426175Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-06-16T19:33:15.915Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/net/ip.h",
"include/net/ip6_route.h",
"include/net/route.h",
"net/core/sock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5d1be493d1110c9e720b4c51a6e587bb2fb4ac12",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
},
{
"lessThan": "a805729c0091073d8f0415cfa96c7acd1bc17a48",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
},
{
"lessThan": "99a2ace61b211b0be861b07fbaa062fca4b58879",
"status": "affected",
"version": "4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/net/ip.h",
"include/net/ip6_route.h",
"include/net/route.h",
"net/core/sock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.13"
},
{
"lessThan": "4.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.64",
"versionStartIncluding": "4.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.3",
"versionStartIncluding": "4.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "4.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u003edev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu()."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:44:07.195Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5d1be493d1110c9e720b4c51a6e587bb2fb4ac12"
},
{
"url": "https://git.kernel.org/stable/c/a805729c0091073d8f0415cfa96c7acd1bc17a48"
},
{
"url": "https://git.kernel.org/stable/c/99a2ace61b211b0be861b07fbaa062fca4b58879"
}
],
"title": "net: use dst_dev_rcu() in sk_setup_caps()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-40170",
"datePublished": "2025-11-12T10:46:52.014Z",
"dateReserved": "2025-04-16T07:20:57.176Z",
"dateUpdated": "2026-06-16T19:33:20.303Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
MSRC_CVE-2025-40170
Vulnerability from csaf_microsoft - Published: 2025-11-13 01:02 - Updated: 2026-09-23 02:31OESA-2025-2772 (CVE-2021-47653)
Vulnerability from osv_openeuler – Published: 2025-12-05 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
media: davinci: vpif: fix use-after-free on driver unbind
The driver allocates and registers two platform device structures during probe, but the devices were never deregistered on driver unbind.
This results in a use-after-free on driver unbind as the device structures were allocated using devres and would be freed by driver core when remove() returns.
Fix this by adding the missing deregistration calls to the remove() callback and failing probe on registration errors.
Note that the platform device structures must be freed using a proper release callback to avoid leaking associated resources like device names.(CVE-2021-47653)
In the Linux kernel, the following vulnerability has been resolved:
mmc: core: use sysfs_emit() instead of sprintf()
sprintf() (still used in the MMC core for the sysfs output) is vulnerable to the buffer overflow. Use the new-fangled sysfs_emit() instead.
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2022-49267)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event
We should not access skb buffer data anymore after hci_recv_frame was called.
[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0 [ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker [ 39.634962] Call trace: [ 39.634974] dump_backtrace+0x0/0x3b8 [ 39.634999] show_stack+0x20/0x2c [ 39.635016] dump_stack_lvl+0x60/0x78 [ 39.635040] print_address_description+0x70/0x2f0 [ 39.635062] kasan_report+0x154/0x194 [ 39.635079] __asan_report_load1_noabort+0x44/0x50 [ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4 [ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4 [ 39.635157] process_one_work+0x560/0xc5c [ 39.635177] worker_thread+0x7ec/0xcc0 [ 39.635195] kthread+0x2d0/0x3d0 [ 39.635215] ret_from_fork+0x10/0x20 [ 39.635247] Allocated by task 0: [ 39.635260] (stack is not available) [ 39.635281] Freed by task 2392: [ 39.635295] kasan_save_stack+0x38/0x68 [ 39.635319] kasan_set_track+0x28/0x3c [ 39.635338] kasan_set_free_info+0x28/0x4c [ 39.635357] _kasanslab_free+0x104/0x150 [ 39.635374] kasan_slab_free+0x18/0x28 [ 39.635391] slab_free_freelist_hook+0x114/0x248 [ 39.635410] kfree+0xf8/0x2b4 [ 39.635427] skb_free_head+0x58/0x98 [ 39.635447] skb_release_data+0x2f4/0x410 [ 39.635464] skb_release_all+0x50/0x60 [ 39.635481] kfree_skb+0xc8/0x25c [ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth] [ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth] [ 39.635925] process_one_work+0x560/0xc5c [ 39.635951] worker_thread+0x7ec/0xcc0 [ 39.635970] kthread+0x2d0/0x3d0 [ 39.635990] ret_from_fork+0x10/0x20 [ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512 [ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800)(CVE-2022-49470)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free
Fix potential use-after-free in l2cap_le_command_rej.(CVE-2023-53305)
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: Fix skb_under_panic in ip6mr_cache_report()
skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x152/0x1d0 Call Trace: <TASK> skb_push+0xc4/0xe0 ip6mr_cache_report+0xd69/0x19b0 reg_vif_xmit+0x406/0x690 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 vlan_dev_hard_start_xmit+0x3ab/0x5c0 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 neigh_connected_output+0x3ed/0x570 ip6_finish_output2+0x5b5/0x1950 ip6_finish_output+0x693/0x11c0 ip6_output+0x24b/0x880 NF_HOOK.constprop.0+0xfd/0x530 ndisc_send_skb+0x9db/0x1400 ndisc_send_rs+0x12a/0x6c0 addrconf_dad_completed+0x3c9/0xea0 addrconf_dad_work+0x849/0x1420 process_one_work+0xa22/0x16e0 worker_thread+0x679/0x10c0 ret_from_fork+0x28/0x60 ret_from_fork_asm+0x11/0x20
When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit(). reg_vif_xmit() ip6mr_cache_report() skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4 And skb_push declared as: void skb_push(struct sk_buff skb, unsigned int len); skb->data -= len; //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850 skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.(CVE-2023-53365)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix handling of lrbp->cmd
ufshcd_queuecommand() may be called two times in a row for a SCSI command before it is completed. Hence make the following changes:
-
In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths.
-
In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.
See also scsi_send_eh_cmnd().
This commit prevents that the following appears if a command times out:
WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0(CVE-2023-53510)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: socinfo: Avoid out of bounds read of serial number
On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always:
db410c:/sys/devices/soc0$ cat serial_number 2644893864
The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the end of the serial_num is within bounds, instead of comparing with the start offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM.
Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.(CVE-2024-58007)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add check read-only before txBeginAnon() call
Added a read-only check before calling txBeginAnon in extAlloc
and extRecord. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.
Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: properly synchronize freeing resources during CPU hotunplug
In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.
If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).
The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed.
Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.
The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.
Previously a fix was attempted by holding cpus_read_lock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2].
Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in handling the race between the refcount dropping to zero in zswap_[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.
[1]https://lkml.kernel.org/(CVE-2025-21693)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb2_lock
If smb_lock->zero_len has value, ->llist of smb_lock is not delete and flock is old one. It will cause use-after-free on error handling routine.(CVE-2025-21945)
In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After complete becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user s PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.(CVE-2025-37786)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in session logoff
The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user.(CVE-2025-37899)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: displayport: Fix NULL pointer access
This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.(CVE-2025-37994)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix region locking in hash types
Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.(CVE-2025-37997)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: unshare page tables during VMA split, not before
Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split.
Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked.
An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts:
- from hugetlb_split(), holding:
- mmap lock (exclusively)
- VMA lock
- file rmap lock (exclusively)
- hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock
Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back.
[(CVE-2025-38084)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix race condition on qfq_aggregate
A race condition can occur when 'agg' is modified in qfq_change_agg (called during qfq_enqueue) while other threads access it concurrently. For example, qfq_dump_class may trigger a NULL dereference, and qfq_delete_class may cause a use-after-free.
This patch addresses the issue by:
-
Moved qfq_destroy_class into the critical section.
-
Added sch_tree_lock protection to qfq_dump_class and qfq_dump_class_stats.(CVE-2025-38477)
In the Linux kernel, the following vulnerability has been resolved:
efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare
Observed on kernel 6.6 (present on master as well):
BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0
If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename:
T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list
lookup_open
d_alloc_parallel
__d_lookup_rcu
__d_lookup_rcu_op_compare
hlist_bl_for_each_entry_rcu
// invalid dentry can be retrieved
->d_compare
efivarfs_d_compare
// oob
Fix it by checking 'guid' before cmp.(CVE-2025-39817)
In the Linux kernel, the following vulnerability has been resolved:
media: tuner: xc5000: Fix use-after-free in xc5000_release
The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv.
A typical race condition is illustrated below:
CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated.
A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here.
This bug was initially identified through static analysis.
hverkuil: fix typo in Subject: tunner -> tuner
In the Linux kernel, the Squashfs filesystem contains an uninitialized value vulnerability. When open_by_handle_at() is called with a file handle containing an invalid parent inode number (specifically that of a symbolic link rather than a directory), squashfs_get_parent() accesses the uninitialized parent member field, causing an uninitialized value access. The fix initializes the parent field with the invalid inode 0.(CVE-2025-40049)
In the Linux kernel, a use-after-free vulnerability exists in the TLS module's get_netdev_for_sock() function. This function is called during setsockopt() operations without RCU protection. Using sk_dst_get(sk)->dev could trigger use-after-free, potentially causing program crashes, unexpected value usage, or arbitrary code execution.(CVE-2025-40149)
A security vulnerability was discovered in the Linux kernel network subsystem involving inadequate RCU (Read-Copy-Update) protection for accesses to dst->dev. The affected functions include sk_setup_caps(), sk_dst_gso_max_size(), ip6_dst_mtu_maybe_forward(), ip_dst_mtu_maybe_forward(), and ip4_dst_hoplimit(). An attacker could potentially exploit this vulnerability to cause privilege escalation or system crashes.(CVE-2025-40170)
In the Linux kernel, the SCTP protocol's MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"perf-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-293.0.0.195.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-293.0.0.195.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"perf-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-293.0.0.195.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-293.0.0.195.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-293.0.0.195.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\nmedia: davinci: vpif: fix use-after-free on driver unbind\n\nThe driver allocates and registers two platform device structures during\nprobe, but the devices were never deregistered on driver unbind.\n\nThis results in a use-after-free on driver unbind as the device\nstructures were allocated using devres and would be freed by driver\ncore when remove() returns.\n\nFix this by adding the missing deregistration calls to the remove()\ncallback and failing probe on registration errors.\n\nNote that the platform device structures must be freed using a proper\nrelease callback to avoid leaking associated resources like device\nnames.(CVE-2021-47653)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: core: use sysfs_emit() instead of sprintf()\n\nsprintf() (still used in the MMC core for the sysfs output) is vulnerable\nto the buffer overflow. Use the new-fangled sysfs_emit() instead.\n\nFound by Linux Verification Center (linuxtesting.org) with the SVACE static\nanalysis tool.(CVE-2022-49267)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event\n\nWe should not access skb buffer data anymore after hci_recv_frame was\ncalled.\n\n[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0\n[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker\n[ 39.634962] Call trace:\n[ 39.634974] dump_backtrace+0x0/0x3b8\n[ 39.634999] show_stack+0x20/0x2c\n[ 39.635016] dump_stack_lvl+0x60/0x78\n[ 39.635040] print_address_description+0x70/0x2f0\n[ 39.635062] kasan_report+0x154/0x194\n[ 39.635079] __asan_report_load1_noabort+0x44/0x50\n[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4\n[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4\n[ 39.635157] process_one_work+0x560/0xc5c\n[ 39.635177] worker_thread+0x7ec/0xcc0\n[ 39.635195] kthread+0x2d0/0x3d0\n[ 39.635215] ret_from_fork+0x10/0x20\n[ 39.635247] Allocated by task 0:\n[ 39.635260] (stack is not available)\n[ 39.635281] Freed by task 2392:\n[ 39.635295] kasan_save_stack+0x38/0x68\n[ 39.635319] kasan_set_track+0x28/0x3c\n[ 39.635338] kasan_set_free_info+0x28/0x4c\n[ 39.635357] ____kasan_slab_free+0x104/0x150\n[ 39.635374] __kasan_slab_free+0x18/0x28\n[ 39.635391] slab_free_freelist_hook+0x114/0x248\n[ 39.635410] kfree+0xf8/0x2b4\n[ 39.635427] skb_free_head+0x58/0x98\n[ 39.635447] skb_release_data+0x2f4/0x410\n[ 39.635464] skb_release_all+0x50/0x60\n[ 39.635481] kfree_skb+0xc8/0x25c\n[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth]\n[ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth]\n[ 39.635925] process_one_work+0x560/0xc5c\n[ 39.635951] worker_thread+0x7ec/0xcc0\n[ 39.635970] kthread+0x2d0/0x3d0\n[ 39.635990] ret_from_fork+0x10/0x20\n[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600\n which belongs to the cache kmalloc-512 of size 512\n[ 39.636039] The buggy address is located 13 bytes inside of\n 512-byte region [ffffff80cf28a600, ffffff80cf28a800)(CVE-2022-49470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free\n\nFix potential use-after-free in l2cap_le_command_rej.(CVE-2023-53305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6mr: Fix skb_under_panic in ip6mr_cache_report()\n\nskbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4\n head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg\n ------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:192!\n invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Workqueue: ipv6_addrconf addrconf_dad_work\n RIP: 0010:skb_panic+0x152/0x1d0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n skb_push+0xc4/0xe0\n ip6mr_cache_report+0xd69/0x19b0\n reg_vif_xmit+0x406/0x690\n dev_hard_start_xmit+0x17e/0x6e0\n __dev_queue_xmit+0x2d6a/0x3d20\n vlan_dev_hard_start_xmit+0x3ab/0x5c0\n dev_hard_start_xmit+0x17e/0x6e0\n __dev_queue_xmit+0x2d6a/0x3d20\n neigh_connected_output+0x3ed/0x570\n ip6_finish_output2+0x5b5/0x1950\n ip6_finish_output+0x693/0x11c0\n ip6_output+0x24b/0x880\n NF_HOOK.constprop.0+0xfd/0x530\n ndisc_send_skb+0x9db/0x1400\n ndisc_send_rs+0x12a/0x6c0\n addrconf_dad_completed+0x3c9/0xea0\n addrconf_dad_work+0x849/0x1420\n process_one_work+0xa22/0x16e0\n worker_thread+0x679/0x10c0\n ret_from_fork+0x28/0x60\n ret_from_fork_asm+0x11/0x20\n\nWhen setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().\nreg_vif_xmit()\n ip6mr_cache_report()\n skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4\nAnd skb_push declared as:\n\tvoid *skb_push(struct sk_buff *skb, unsigned int len);\n\t\tskb-\u0026gt;data -= len;\n\t\t//0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850\nskb-\u0026gt;data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.(CVE-2023-53365)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix handling of lrbp-\u0026gt;cmd\n\nufshcd_queuecommand() may be called two times in a row for a SCSI command\nbefore it is completed. Hence make the following changes:\n\n - In the functions that submit a command, do not check the old value of\n lrbp-\u0026gt;cmd nor clear lrbp-\u0026gt;cmd in error paths.\n\n - In ufshcd_release_scsi_cmd(), do not clear lrbp-\u0026gt;cmd.\n\nSee also scsi_send_eh_cmnd().\n\nThis commit prevents that the following appears if a command times out:\n\nWARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8\nCall trace:\n ufshcd_queuecommand+0x6f8/0x9a8\n scsi_send_eh_cmnd+0x2c0/0x960\n scsi_eh_test_devices+0x100/0x314\n scsi_eh_ready_devs+0xd90/0x114c\n scsi_error_handler+0x2b4/0xb70\n kthread+0x16c/0x1e0(CVE-2023-53510)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: socinfo: Avoid out of bounds read of serial number\n\nOn MSM8916 devices, the serial number exposed in sysfs is constant and does\nnot change across individual devices. It\u0026apos;s always:\n\n db410c:/sys/devices/soc0$ cat serial_number\n 2644893864\n\nThe firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not\nhave support for the serial_num field in the socinfo struct. There is an\nexisting check to avoid exposing the serial number in that case, but it\u0026apos;s\nnot correct: When checking the item_size returned by SMEM, we need to make\nsure the *end* of the serial_num is within bounds, instead of comparing\nwith the *start* offset. The serial_number currently exposed on MSM8916\ndevices is just an out of bounds read of whatever comes after the socinfo\nstruct in SMEM.\n\nFix this by changing offsetof() to offsetofend(), so that the size of the\nfield is also taken into account.(CVE-2024-58007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before txBeginAnon() call\n\nAdded a read-only check before calling `txBeginAnon` in `extAlloc`\nand `extRecord`. This prevents modification attempts on a read-only\nmounted filesystem, avoiding potential errors or crashes.\n\nCall trace:\n txBeginAnon+0xac/0x154\n extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78\n jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248\n __block_write_begin_int+0x580/0x166c fs/buffer.c:2128\n __block_write_begin fs/buffer.c:2177 [inline]\n block_write_begin+0x98/0x11c fs/buffer.c:2236\n jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: properly synchronize freeing resources during CPU hotunplug\n\nIn zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the\ncurrent CPU at the beginning of the operation is retrieved and used\nthroughout. However, since neither preemption nor migration are disabled,\nit is possible that the operation continues on a different CPU.\n\nIf the original CPU is hotunplugged while the acomp_ctx is still in use,\nwe run into a UAF bug as some of the resources attached to the acomp_ctx\nare freed during hotunplug in zswap_cpu_comp_dead() (i.e. \nacomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).\n\nThe problem was introduced in commit 1ec3b5fe6eec (\u0026quot;mm/zswap: move to use\ncrypto_acomp API for hardware acceleration\u0026quot;) when the switch to the\ncrypto_acomp API was made. Prior to that, the per-CPU crypto_comp was\nretrieved using get_cpu_ptr() which disables preemption and makes sure the\nCPU cannot go away from under us. Preemption cannot be disabled with the\ncrypto_acomp API as a sleepable context is needed.\n\nUse the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating\nand freeing resources with compression/decompression paths. Make sure\nthat acomp_ctx.req is NULL when the resources are freed. In the\ncompression/decompression paths, check if acomp_ctx.req is NULL after\nacquiring the mutex (meaning the CPU was offlined) and retry on the new\nCPU.\n\nThe initialization of acomp_ctx.mutex is moved from the CPU hotplug\ncallback to the pool initialization where it belongs (where the mutex is\nallocated). In addition to adding clarity, this makes sure that CPU\nhotplug cannot reinitialize a mutex that is already locked by\ncompression/decompression.\n\nPreviously a fix was attempted by holding cpus_read_lock() [1]. This\nwould have caused a potential deadlock as it is possible for code already\nholding the lock to fall into reclaim and enter zswap (causing a\ndeadlock). A fix was also attempted using SRCU for synchronization, but\nJohannes pointed out that synchronize_srcu() cannot be used in CPU hotplug\nnotifiers [2].\n\nAlternative fixes that were considered/attempted and could have worked:\n- Refcounting the per-CPU acomp_ctx. This involves complexity in\n handling the race between the refcount dropping to zero in\n zswap_[de]compress() and the refcount being re-initialized when the\n CPU is onlined.\n- Disabling migration before getting the per-CPU acomp_ctx [3], but\n that\u0026apos;s discouraged and is a much bigger hammer than needed, and could\n result in subtle performance issues.\n\n[1]https://lkml.kernel.org/(CVE-2025-21693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb2_lock\n\nIf smb_lock-\u0026gt;zero_len has value, -\u0026gt;llist of smb_lock is not delete and\nflock is old one. It will cause use-after-free on error handling\nroutine.(CVE-2025-21945)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After complete becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree sdst-\u0026gt;ports, and maybe dst-\u0026gt;rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user s PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst-\u0026gt;ports. However, the dst-\u0026gt;rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds-\u0026gt;ops-\u0026gt;setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst-\u0026gt;rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst-\u0026gt;rtable. Prior to that, each switch had its ownds-\u0026gt;rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.(CVE-2025-37786)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in session logoff\n\nThe sess-\u0026gt;user object can currently be in use by another thread, for\nexample if another connection has sent a session setup request to\nbind to the session being free\u0026apos;d. The handler for that connection could\nbe in the smb2_sess_setup function which makes use of sess-\u0026gt;user.(CVE-2025-37899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix NULL pointer access\n\nThis patch ensures that the UCSI driver waits for all pending tasks in the\nucsi_displayport_work workqueue to finish executing before proceeding with\nthe partner removal.(CVE-2025-37994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix region locking in hash types\n\nRegion locking introduced in v5.6-rc4 contained three macros to handle\nthe region locks: ahash_bucket_start(), ahash_bucket_end() which gave\nback the start and end hash bucket values belonging to a given region\nlock and ahash_region() which should give back the region lock belonging\nto a given hash bucket. The latter was incorrect which can lead to a\nrace condition between the garbage collector and adding new elements\nwhen a hash type of set is defined with timeouts.(CVE-2025-37997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: unshare page tables during VMA split, not before\n\nCurrently, __split_vma() triggers hugetlb page table unsharing through\nvm_ops-\u0026gt;may_split(). This happens before the VMA lock and rmap locks are\ntaken - which is too early, it allows racing VMA-locked page faults in our\nprocess and racing rmap walks from other processes to cause page tables to\nbe shared again before we actually perform the split.\n\nFix it by explicitly calling into the hugetlb unshare logic from\n__split_vma() in the same place where THP splitting also happens. At that\npoint, both the VMA and the rmap(s) are write-locked.\n\nAn annoying detail is that we can now call into the helper\nhugetlb_unshare_pmds() from two different locking contexts:\n\n1. from hugetlb_split(), holding:\n - mmap lock (exclusively)\n - VMA lock\n - file rmap lock (exclusively)\n2. hugetlb_unshare_all_pmds(), which I think is designed to be able to\n call us with only the mmap lock held (in shared mode), but currently\n only runs while holding mmap lock (exclusively) and VMA lock\n\nBackporting note:\nThis commit fixes a racy protection that was introduced in commit\nb30c14cd6102 (\u0026quot;hugetlb: unshare some PMDs when splitting VMAs\u0026quot;); that\ncommit claimed to fix an issue introduced in 5.13, but it should actually\nalso go all the way back.\n\n[(CVE-2025-38084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix race condition on qfq_aggregate\n\nA race condition can occur when \u0026apos;agg\u0026apos; is modified in qfq_change_agg\n(called during qfq_enqueue) while other threads access it\nconcurrently. For example, qfq_dump_class may trigger a NULL\ndereference, and qfq_delete_class may cause a use-after-free.\n\nThis patch addresses the issue by:\n\n1. Moved qfq_destroy_class into the critical section.\n\n2. Added sch_tree_lock protection to qfq_dump_class and\nqfq_dump_class_stats.(CVE-2025-38477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: Fix slab-out-of-bounds in efivarfs_d_compare\n\nObserved on kernel 6.6 (present on master as well):\n\n BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0\n Call trace:\n kasan_check_range+0xe8/0x190\n __asan_loadN+0x1c/0x28\n memcmp+0x98/0xd0\n efivarfs_d_compare+0x68/0xd8\n __d_lookup_rcu_op_compare+0x178/0x218\n __d_lookup_rcu+0x1f8/0x228\n d_alloc_parallel+0x150/0x648\n lookup_open.isra.0+0x5f0/0x8d0\n open_last_lookups+0x264/0x828\n path_openat+0x130/0x3f8\n do_filp_open+0x114/0x248\n do_sys_openat2+0x340/0x3c0\n __arm64_sys_openat+0x120/0x1a0\n\nIf dentry-\u0026gt;d_name.len \u0026lt; EFI_VARIABLE_GUID_LEN , \u0026apos;guid\u0026apos; can become\nnegative, leadings to oob. The issue can be triggered by parallel\nlookups using invalid filename:\n\n T1\t\t\tT2\n lookup_open\n -\u0026gt;lookup\n simple_lookup\n d_add\n // invalid dentry is added to hash list\n\n\t\t\tlookup_open\n\t\t\t d_alloc_parallel\n\t\t\t __d_lookup_rcu\n\t\t\t __d_lookup_rcu_op_compare\n\t\t\t hlist_bl_for_each_entry_rcu\n\t\t\t // invalid dentry can be retrieved\n\t\t\t -\u0026gt;d_compare\n\t\t\t efivarfs_d_compare\n\t\t\t // oob\n\nFix it by checking \u0026apos;guid\u0026apos; before cmp.(CVE-2025-39817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: tuner: xc5000: Fix use-after-free in xc5000_release\n\nThe original code uses cancel_delayed_work() in xc5000_release(), which\ndoes not guarantee that the delayed work item timer_sleep has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere xc5000_release() may free the xc5000_priv while timer_sleep is still\nactive and attempts to dereference the xc5000_priv.\n\nA typical race condition is illustrated below:\n\nCPU 0 (release thread) | CPU 1 (delayed work callback)\nxc5000_release() | xc5000_do_timer_sleep()\n cancel_delayed_work() |\n hybrid_tuner_release_state(priv) |\n kfree(priv) |\n | priv = container_of() // UAF\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the timer_sleep is properly canceled before the xc5000_priv memory\nis deallocated.\n\nA deadlock concern was considered: xc5000_release() is called in a process\ncontext and is not holding any locks that the timer_sleep work item might\nalso need. Therefore, the use of the _sync() variant is safe here.\n\nThis bug was initially identified through static analysis.\n\n[hverkuil: fix typo in Subject: tunner -\u0026gt; tuner](CVE-2025-39994)\n\nIn the Linux kernel, the Squashfs filesystem contains an uninitialized value vulnerability. When open_by_handle_at() is called with a file handle containing an invalid parent inode number (specifically that of a symbolic link rather than a directory), squashfs_get_parent() accesses the uninitialized parent member field, causing an uninitialized value access. The fix initializes the parent field with the invalid inode 0.(CVE-2025-40049)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the TLS module\u0026apos;s get_netdev_for_sock() function. This function is called during setsockopt() operations without RCU protection. Using sk_dst_get(sk)-\u0026gt;dev could trigger use-after-free, potentially causing program crashes, unexpected value usage, or arbitrary code execution.(CVE-2025-40149)\n\nA security vulnerability was discovered in the Linux kernel network subsystem involving inadequate RCU (Read-Copy-Update) protection for accesses to dst-\u0026gt;dev. The affected functions include sk_setup_caps(), sk_dst_gso_max_size(), ip6_dst_mtu_maybe_forward(), ip_dst_mtu_maybe_forward(), and ip4_dst_hoplimit(). An attacker could potentially exploit this vulnerability to cause privilege escalation or system crashes.(CVE-2025-40170)\n\nIn the Linux kernel, the SCTP protocol\u0026apos;s MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)",
"id": "OESA-2025-2772",
"modified": "2026-08-06T11:09:53Z",
"published": "2025-12-05T11:09:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49470"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53365"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53510"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37786"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40049"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40204"
}
],
"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-47653",
"CVE-2022-49267",
"CVE-2022-49470",
"CVE-2023-53305",
"CVE-2023-53365",
"CVE-2023-53510",
"CVE-2024-58007",
"CVE-2024-58095",
"CVE-2025-21693",
"CVE-2025-21945",
"CVE-2025-37786",
"CVE-2025-37899",
"CVE-2025-37994",
"CVE-2025-37997",
"CVE-2025-38084",
"CVE-2025-38477",
"CVE-2025-39817",
"CVE-2025-39994",
"CVE-2025-40049",
"CVE-2025-40149",
"CVE-2025-40170",
"CVE-2025-40204"
]
}
OESA-2025-2773 (CVE-2021-47653)
Vulnerability from osv_openeuler – Published: 2025-12-05 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
media: davinci: vpif: fix use-after-free on driver unbind
The driver allocates and registers two platform device structures during probe, but the devices were never deregistered on driver unbind.
This results in a use-after-free on driver unbind as the device structures were allocated using devres and would be freed by driver core when remove() returns.
Fix this by adding the missing deregistration calls to the remove() callback and failing probe on registration errors.
Note that the platform device structures must be freed using a proper release callback to avoid leaking associated resources like device names.(CVE-2021-47653)
In the Linux kernel, the following vulnerability has been resolved:
mmc: core: use sysfs_emit() instead of sprintf()
sprintf() (still used in the MMC core for the sysfs output) is vulnerable to the buffer overflow. Use the new-fangled sysfs_emit() instead.
Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2022-49267)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event
We should not access skb buffer data anymore after hci_recv_frame was called.
[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0 [ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker [ 39.634962] Call trace: [ 39.634974] dump_backtrace+0x0/0x3b8 [ 39.634999] show_stack+0x20/0x2c [ 39.635016] dump_stack_lvl+0x60/0x78 [ 39.635040] print_address_description+0x70/0x2f0 [ 39.635062] kasan_report+0x154/0x194 [ 39.635079] __asan_report_load1_noabort+0x44/0x50 [ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4 [ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4 [ 39.635157] process_one_work+0x560/0xc5c [ 39.635177] worker_thread+0x7ec/0xcc0 [ 39.635195] kthread+0x2d0/0x3d0 [ 39.635215] ret_from_fork+0x10/0x20 [ 39.635247] Allocated by task 0: [ 39.635260] (stack is not available) [ 39.635281] Freed by task 2392: [ 39.635295] kasan_save_stack+0x38/0x68 [ 39.635319] kasan_set_track+0x28/0x3c [ 39.635338] kasan_set_free_info+0x28/0x4c [ 39.635357] _kasanslab_free+0x104/0x150 [ 39.635374] kasan_slab_free+0x18/0x28 [ 39.635391] slab_free_freelist_hook+0x114/0x248 [ 39.635410] kfree+0xf8/0x2b4 [ 39.635427] skb_free_head+0x58/0x98 [ 39.635447] skb_release_data+0x2f4/0x410 [ 39.635464] skb_release_all+0x50/0x60 [ 39.635481] kfree_skb+0xc8/0x25c [ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth] [ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth] [ 39.635925] process_one_work+0x560/0xc5c [ 39.635951] worker_thread+0x7ec/0xcc0 [ 39.635970] kthread+0x2d0/0x3d0 [ 39.635990] ret_from_fork+0x10/0x20 [ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512 [ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800)(CVE-2022-49470)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Fix handling of lrbp->cmd
ufshcd_queuecommand() may be called two times in a row for a SCSI command before it is completed. Hence make the following changes:
-
In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths.
-
In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.
See also scsi_send_eh_cmnd().
This commit prevents that the following appears if a command times out:
WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0(CVE-2023-53510)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: socinfo: Avoid out of bounds read of serial number
On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always:
db410c:/sys/devices/soc0$ cat serial_number 2644893864
The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the end of the serial_num is within bounds, instead of comparing with the start offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM.
Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account.(CVE-2024-58007)
In the Linux kernel, the following vulnerability has been resolved:
jfs: add check read-only before txBeginAnon() call
Added a read-only check before calling txBeginAnon in extAlloc
and extRecord. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.
Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: properly synchronize freeing resources during CPU hotunplug
In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.
If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).
The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed.
Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.
The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.
Previously a fix was attempted by holding cpus_read_lock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2].
Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in handling the race between the refcount dropping to zero in zswap_[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.
[1]https://lkml.kernel.org/(CVE-2025-21693)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb2_lock
If smb_lock->zero_len has value, ->llist of smb_lock is not delete and flock is old one. It will cause use-after-free on error handling routine.(CVE-2025-21945)
In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After complete becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user s PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.(CVE-2025-37786)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in session logoff
The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user.(CVE-2025-37899)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: displayport: Fix NULL pointer access
This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.(CVE-2025-37994)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix region locking in hash types
Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.(CVE-2025-37997)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: unshare page tables during VMA split, not before
Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split.
Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked.
An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts:
- from hugetlb_split(), holding:
- mmap lock (exclusively)
- VMA lock
- file rmap lock (exclusively)
- hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock
Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back.
[(CVE-2025-38084)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix race condition on qfq_aggregate
A race condition can occur when 'agg' is modified in qfq_change_agg (called during qfq_enqueue) while other threads access it concurrently. For example, qfq_dump_class may trigger a NULL dereference, and qfq_delete_class may cause a use-after-free.
This patch addresses the issue by:
-
Moved qfq_destroy_class into the critical section.
-
Added sch_tree_lock protection to qfq_dump_class and qfq_dump_class_stats.(CVE-2025-38477)
In the Linux kernel, the following vulnerability has been resolved:
efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare
Observed on kernel 6.6 (present on master as well):
BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0
If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename:
T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list
lookup_open
d_alloc_parallel
__d_lookup_rcu
__d_lookup_rcu_op_compare
hlist_bl_for_each_entry_rcu
// invalid dentry can be retrieved
->d_compare
efivarfs_d_compare
// oob
Fix it by checking 'guid' before cmp.(CVE-2025-39817)
In the Linux kernel, the following vulnerability has been resolved:
media: tuner: xc5000: Fix use-after-free in xc5000_release
The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv.
A typical race condition is illustrated below:
CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated.
A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here.
This bug was initially identified through static analysis.
hverkuil: fix typo in Subject: tunner -> tuner
In the Linux kernel, the Squashfs filesystem contains an uninitialized value vulnerability. When open_by_handle_at() is called with a file handle containing an invalid parent inode number (specifically that of a symbolic link rather than a directory), squashfs_get_parent() accesses the uninitialized parent member field, causing an uninitialized value access. The fix initializes the parent field with the invalid inode 0.(CVE-2025-40049)
In the Linux kernel, a use-after-free vulnerability exists in the TLS module's get_netdev_for_sock() function. This function is called during setsockopt() operations without RCU protection. Using sk_dst_get(sk)->dev could trigger use-after-free, potentially causing program crashes, unexpected value usage, or arbitrary code execution.(CVE-2025-40149)
A security vulnerability was discovered in the Linux kernel network subsystem involving inadequate RCU (Read-Copy-Update) protection for accesses to dst->dev. The affected functions include sk_setup_caps(), sk_dst_gso_max_size(), ip6_dst_mtu_maybe_forward(), ip_dst_mtu_maybe_forward(), and ip4_dst_hoplimit(). An attacker could potentially exploit this vulnerability to cause privilege escalation or system crashes.(CVE-2025-40170)
In the Linux kernel, the SCTP protocol's MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"perf-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-293.0.0.196.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-293.0.0.196.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"perf-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-293.0.0.196.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-293.0.0.196.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-293.0.0.196.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\nmedia: davinci: vpif: fix use-after-free on driver unbind\n\nThe driver allocates and registers two platform device structures during\nprobe, but the devices were never deregistered on driver unbind.\n\nThis results in a use-after-free on driver unbind as the device\nstructures were allocated using devres and would be freed by driver\ncore when remove() returns.\n\nFix this by adding the missing deregistration calls to the remove()\ncallback and failing probe on registration errors.\n\nNote that the platform device structures must be freed using a proper\nrelease callback to avoid leaking associated resources like device\nnames.(CVE-2021-47653)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: core: use sysfs_emit() instead of sprintf()\n\nsprintf() (still used in the MMC core for the sysfs output) is vulnerable\nto the buffer overflow. Use the new-fangled sysfs_emit() instead.\n\nFound by Linux Verification Center (linuxtesting.org) with the SVACE static\nanalysis tool.(CVE-2022-49267)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event\n\nWe should not access skb buffer data anymore after hci_recv_frame was\ncalled.\n\n[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0\n[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker\n[ 39.634962] Call trace:\n[ 39.634974] dump_backtrace+0x0/0x3b8\n[ 39.634999] show_stack+0x20/0x2c\n[ 39.635016] dump_stack_lvl+0x60/0x78\n[ 39.635040] print_address_description+0x70/0x2f0\n[ 39.635062] kasan_report+0x154/0x194\n[ 39.635079] __asan_report_load1_noabort+0x44/0x50\n[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4\n[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4\n[ 39.635157] process_one_work+0x560/0xc5c\n[ 39.635177] worker_thread+0x7ec/0xcc0\n[ 39.635195] kthread+0x2d0/0x3d0\n[ 39.635215] ret_from_fork+0x10/0x20\n[ 39.635247] Allocated by task 0:\n[ 39.635260] (stack is not available)\n[ 39.635281] Freed by task 2392:\n[ 39.635295] kasan_save_stack+0x38/0x68\n[ 39.635319] kasan_set_track+0x28/0x3c\n[ 39.635338] kasan_set_free_info+0x28/0x4c\n[ 39.635357] ____kasan_slab_free+0x104/0x150\n[ 39.635374] __kasan_slab_free+0x18/0x28\n[ 39.635391] slab_free_freelist_hook+0x114/0x248\n[ 39.635410] kfree+0xf8/0x2b4\n[ 39.635427] skb_free_head+0x58/0x98\n[ 39.635447] skb_release_data+0x2f4/0x410\n[ 39.635464] skb_release_all+0x50/0x60\n[ 39.635481] kfree_skb+0xc8/0x25c\n[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth]\n[ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth]\n[ 39.635925] process_one_work+0x560/0xc5c\n[ 39.635951] worker_thread+0x7ec/0xcc0\n[ 39.635970] kthread+0x2d0/0x3d0\n[ 39.635990] ret_from_fork+0x10/0x20\n[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600\n which belongs to the cache kmalloc-512 of size 512\n[ 39.636039] The buggy address is located 13 bytes inside of\n 512-byte region [ffffff80cf28a600, ffffff80cf28a800)(CVE-2022-49470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix handling of lrbp-\u0026gt;cmd\n\nufshcd_queuecommand() may be called two times in a row for a SCSI command\nbefore it is completed. Hence make the following changes:\n\n - In the functions that submit a command, do not check the old value of\n lrbp-\u0026gt;cmd nor clear lrbp-\u0026gt;cmd in error paths.\n\n - In ufshcd_release_scsi_cmd(), do not clear lrbp-\u0026gt;cmd.\n\nSee also scsi_send_eh_cmnd().\n\nThis commit prevents that the following appears if a command times out:\n\nWARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8\nCall trace:\n ufshcd_queuecommand+0x6f8/0x9a8\n scsi_send_eh_cmnd+0x2c0/0x960\n scsi_eh_test_devices+0x100/0x314\n scsi_eh_ready_devs+0xd90/0x114c\n scsi_error_handler+0x2b4/0xb70\n kthread+0x16c/0x1e0(CVE-2023-53510)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: socinfo: Avoid out of bounds read of serial number\n\nOn MSM8916 devices, the serial number exposed in sysfs is constant and does\nnot change across individual devices. It\u0026apos;s always:\n\n db410c:/sys/devices/soc0$ cat serial_number\n 2644893864\n\nThe firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not\nhave support for the serial_num field in the socinfo struct. There is an\nexisting check to avoid exposing the serial number in that case, but it\u0026apos;s\nnot correct: When checking the item_size returned by SMEM, we need to make\nsure the *end* of the serial_num is within bounds, instead of comparing\nwith the *start* offset. The serial_number currently exposed on MSM8916\ndevices is just an out of bounds read of whatever comes after the socinfo\nstruct in SMEM.\n\nFix this by changing offsetof() to offsetofend(), so that the size of the\nfield is also taken into account.(CVE-2024-58007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: add check read-only before txBeginAnon() call\n\nAdded a read-only check before calling `txBeginAnon` in `extAlloc`\nand `extRecord`. This prevents modification attempts on a read-only\nmounted filesystem, avoiding potential errors or crashes.\n\nCall trace:\n txBeginAnon+0xac/0x154\n extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78\n jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248\n __block_write_begin_int+0x580/0x166c fs/buffer.c:2128\n __block_write_begin fs/buffer.c:2177 [inline]\n block_write_begin+0x98/0x11c fs/buffer.c:2236\n jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299(CVE-2024-58095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: properly synchronize freeing resources during CPU hotunplug\n\nIn zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the\ncurrent CPU at the beginning of the operation is retrieved and used\nthroughout. However, since neither preemption nor migration are disabled,\nit is possible that the operation continues on a different CPU.\n\nIf the original CPU is hotunplugged while the acomp_ctx is still in use,\nwe run into a UAF bug as some of the resources attached to the acomp_ctx\nare freed during hotunplug in zswap_cpu_comp_dead() (i.e. \nacomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).\n\nThe problem was introduced in commit 1ec3b5fe6eec (\u0026quot;mm/zswap: move to use\ncrypto_acomp API for hardware acceleration\u0026quot;) when the switch to the\ncrypto_acomp API was made. Prior to that, the per-CPU crypto_comp was\nretrieved using get_cpu_ptr() which disables preemption and makes sure the\nCPU cannot go away from under us. Preemption cannot be disabled with the\ncrypto_acomp API as a sleepable context is needed.\n\nUse the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating\nand freeing resources with compression/decompression paths. Make sure\nthat acomp_ctx.req is NULL when the resources are freed. In the\ncompression/decompression paths, check if acomp_ctx.req is NULL after\nacquiring the mutex (meaning the CPU was offlined) and retry on the new\nCPU.\n\nThe initialization of acomp_ctx.mutex is moved from the CPU hotplug\ncallback to the pool initialization where it belongs (where the mutex is\nallocated). In addition to adding clarity, this makes sure that CPU\nhotplug cannot reinitialize a mutex that is already locked by\ncompression/decompression.\n\nPreviously a fix was attempted by holding cpus_read_lock() [1]. This\nwould have caused a potential deadlock as it is possible for code already\nholding the lock to fall into reclaim and enter zswap (causing a\ndeadlock). A fix was also attempted using SRCU for synchronization, but\nJohannes pointed out that synchronize_srcu() cannot be used in CPU hotplug\nnotifiers [2].\n\nAlternative fixes that were considered/attempted and could have worked:\n- Refcounting the per-CPU acomp_ctx. This involves complexity in\n handling the race between the refcount dropping to zero in\n zswap_[de]compress() and the refcount being re-initialized when the\n CPU is onlined.\n- Disabling migration before getting the per-CPU acomp_ctx [3], but\n that\u0026apos;s discouraged and is a much bigger hammer than needed, and could\n result in subtle performance issues.\n\n[1]https://lkml.kernel.org/(CVE-2025-21693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb2_lock\n\nIf smb_lock-\u0026gt;zero_len has value, -\u0026gt;llist of smb_lock is not delete and\nflock is old one. It will cause use-after-free on error handling\nroutine.(CVE-2025-21945)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After complete becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree sdst-\u0026gt;ports, and maybe dst-\u0026gt;rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user s PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst-\u0026gt;ports. However, the dst-\u0026gt;rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds-\u0026gt;ops-\u0026gt;setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst-\u0026gt;rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst-\u0026gt;rtable. Prior to that, each switch had its ownds-\u0026gt;rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.(CVE-2025-37786)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in session logoff\n\nThe sess-\u0026gt;user object can currently be in use by another thread, for\nexample if another connection has sent a session setup request to\nbind to the session being free\u0026apos;d. The handler for that connection could\nbe in the smb2_sess_setup function which makes use of sess-\u0026gt;user.(CVE-2025-37899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: displayport: Fix NULL pointer access\n\nThis patch ensures that the UCSI driver waits for all pending tasks in the\nucsi_displayport_work workqueue to finish executing before proceeding with\nthe partner removal.(CVE-2025-37994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix region locking in hash types\n\nRegion locking introduced in v5.6-rc4 contained three macros to handle\nthe region locks: ahash_bucket_start(), ahash_bucket_end() which gave\nback the start and end hash bucket values belonging to a given region\nlock and ahash_region() which should give back the region lock belonging\nto a given hash bucket. The latter was incorrect which can lead to a\nrace condition between the garbage collector and adding new elements\nwhen a hash type of set is defined with timeouts.(CVE-2025-37997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: unshare page tables during VMA split, not before\n\nCurrently, __split_vma() triggers hugetlb page table unsharing through\nvm_ops-\u0026gt;may_split(). This happens before the VMA lock and rmap locks are\ntaken - which is too early, it allows racing VMA-locked page faults in our\nprocess and racing rmap walks from other processes to cause page tables to\nbe shared again before we actually perform the split.\n\nFix it by explicitly calling into the hugetlb unshare logic from\n__split_vma() in the same place where THP splitting also happens. At that\npoint, both the VMA and the rmap(s) are write-locked.\n\nAn annoying detail is that we can now call into the helper\nhugetlb_unshare_pmds() from two different locking contexts:\n\n1. from hugetlb_split(), holding:\n - mmap lock (exclusively)\n - VMA lock\n - file rmap lock (exclusively)\n2. hugetlb_unshare_all_pmds(), which I think is designed to be able to\n call us with only the mmap lock held (in shared mode), but currently\n only runs while holding mmap lock (exclusively) and VMA lock\n\nBackporting note:\nThis commit fixes a racy protection that was introduced in commit\nb30c14cd6102 (\u0026quot;hugetlb: unshare some PMDs when splitting VMAs\u0026quot;); that\ncommit claimed to fix an issue introduced in 5.13, but it should actually\nalso go all the way back.\n\n[(CVE-2025-38084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix race condition on qfq_aggregate\n\nA race condition can occur when \u0026apos;agg\u0026apos; is modified in qfq_change_agg\n(called during qfq_enqueue) while other threads access it\nconcurrently. For example, qfq_dump_class may trigger a NULL\ndereference, and qfq_delete_class may cause a use-after-free.\n\nThis patch addresses the issue by:\n\n1. Moved qfq_destroy_class into the critical section.\n\n2. Added sch_tree_lock protection to qfq_dump_class and\nqfq_dump_class_stats.(CVE-2025-38477)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: Fix slab-out-of-bounds in efivarfs_d_compare\n\nObserved on kernel 6.6 (present on master as well):\n\n BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0\n Call trace:\n kasan_check_range+0xe8/0x190\n __asan_loadN+0x1c/0x28\n memcmp+0x98/0xd0\n efivarfs_d_compare+0x68/0xd8\n __d_lookup_rcu_op_compare+0x178/0x218\n __d_lookup_rcu+0x1f8/0x228\n d_alloc_parallel+0x150/0x648\n lookup_open.isra.0+0x5f0/0x8d0\n open_last_lookups+0x264/0x828\n path_openat+0x130/0x3f8\n do_filp_open+0x114/0x248\n do_sys_openat2+0x340/0x3c0\n __arm64_sys_openat+0x120/0x1a0\n\nIf dentry-\u0026gt;d_name.len \u0026lt; EFI_VARIABLE_GUID_LEN , \u0026apos;guid\u0026apos; can become\nnegative, leadings to oob. The issue can be triggered by parallel\nlookups using invalid filename:\n\n T1\t\t\tT2\n lookup_open\n -\u0026gt;lookup\n simple_lookup\n d_add\n // invalid dentry is added to hash list\n\n\t\t\tlookup_open\n\t\t\t d_alloc_parallel\n\t\t\t __d_lookup_rcu\n\t\t\t __d_lookup_rcu_op_compare\n\t\t\t hlist_bl_for_each_entry_rcu\n\t\t\t // invalid dentry can be retrieved\n\t\t\t -\u0026gt;d_compare\n\t\t\t efivarfs_d_compare\n\t\t\t // oob\n\nFix it by checking \u0026apos;guid\u0026apos; before cmp.(CVE-2025-39817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: tuner: xc5000: Fix use-after-free in xc5000_release\n\nThe original code uses cancel_delayed_work() in xc5000_release(), which\ndoes not guarantee that the delayed work item timer_sleep has fully\ncompleted if it was already running. This leads to use-after-free scenarios\nwhere xc5000_release() may free the xc5000_priv while timer_sleep is still\nactive and attempts to dereference the xc5000_priv.\n\nA typical race condition is illustrated below:\n\nCPU 0 (release thread) | CPU 1 (delayed work callback)\nxc5000_release() | xc5000_do_timer_sleep()\n cancel_delayed_work() |\n hybrid_tuner_release_state(priv) |\n kfree(priv) |\n | priv = container_of() // UAF\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the timer_sleep is properly canceled before the xc5000_priv memory\nis deallocated.\n\nA deadlock concern was considered: xc5000_release() is called in a process\ncontext and is not holding any locks that the timer_sleep work item might\nalso need. Therefore, the use of the _sync() variant is safe here.\n\nThis bug was initially identified through static analysis.\n\n[hverkuil: fix typo in Subject: tunner -\u0026gt; tuner](CVE-2025-39994)\n\nIn the Linux kernel, the Squashfs filesystem contains an uninitialized value vulnerability. When open_by_handle_at() is called with a file handle containing an invalid parent inode number (specifically that of a symbolic link rather than a directory), squashfs_get_parent() accesses the uninitialized parent member field, causing an uninitialized value access. The fix initializes the parent field with the invalid inode 0.(CVE-2025-40049)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the TLS module\u0026apos;s get_netdev_for_sock() function. This function is called during setsockopt() operations without RCU protection. Using sk_dst_get(sk)-\u0026gt;dev could trigger use-after-free, potentially causing program crashes, unexpected value usage, or arbitrary code execution.(CVE-2025-40149)\n\nA security vulnerability was discovered in the Linux kernel network subsystem involving inadequate RCU (Read-Copy-Update) protection for accesses to dst-\u0026gt;dev. The affected functions include sk_setup_caps(), sk_dst_gso_max_size(), ip6_dst_mtu_maybe_forward(), ip_dst_mtu_maybe_forward(), and ip4_dst_hoplimit(). An attacker could potentially exploit this vulnerability to cause privilege escalation or system crashes.(CVE-2025-40170)\n\nIn the Linux kernel, the SCTP protocol\u0026apos;s MAC comparison implementation was vulnerable to timing attacks. This vulnerability allows attackers to infer MAC values through timing analysis, potentially bypassing security validation. The fix modifies the MAC comparison to use constant-time comparison to prevent timing attacks.(CVE-2025-40204)",
"id": "OESA-2025-2773",
"modified": "2026-08-06T11:09:53Z",
"published": "2025-12-05T11:09:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2773"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49470"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53510"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37786"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38477"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39817"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39994"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40049"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40204"
}
],
"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-47653",
"CVE-2022-49267",
"CVE-2022-49470",
"CVE-2023-53510",
"CVE-2024-58007",
"CVE-2024-58095",
"CVE-2025-21693",
"CVE-2025-21945",
"CVE-2025-37786",
"CVE-2025-37899",
"CVE-2025-37994",
"CVE-2025-37997",
"CVE-2025-38084",
"CVE-2025-38477",
"CVE-2025-39817",
"CVE-2025-39994",
"CVE-2025-40049",
"CVE-2025-40149",
"CVE-2025-40170",
"CVE-2025-40204"
]
}
OESA-2025-2882 (CVE-2024-42154)
Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix the warning from __kernel_write_iter
[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280
This patch doesn't allow writing to directory.(CVE-2025-37775)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb_break_all_levII_oplock()
There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)
In the Linux kernel, the following vulnerability has been resolved:
pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line:
do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.
Fixes the following warning:
drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section
ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Evict cache lines during SNP memory validation
An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.
CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.
Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size
This is inspired by the check for data_offset + data_length.(CVE-2025-39942)
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the
BIT() macro.
Note: other VM_ flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_ flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[(CVE-2025-40040)
In the Linux kernel, the following vulnerability has been resolved:
net: use dst_dev_rcu() in sk_setup_caps()
Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().
Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().
ip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-129.0.0.114.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.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-129.0.0.114.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:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)\n\nIn the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u0026gt;ath10k_core_unregister\n \u2026\u2026\n -\u0026gt;ath10k_core_stop\n -\u0026gt;ath10k_hif_stop\n -\u0026gt;ath10k_sdio_irq_disable\n -\u0026gt;ath10k_hif_power_down\n -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer)\n -\u0026gt;ath10k_core_destroy\n -\u0026gt;ath10k_mac_destroy\n -\u0026gt;ieee80211_free_hw\n -\u0026gt;wiphy_free\n \u2026\u2026\n -\u0026gt;wiphy_dev_release\n -\u0026gt;destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0026apos;t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an \u0026quot;KMSAN: uninit-value\u0026quot; warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n\u0026apos;\u0026apos;\u0026apos;\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, \u0026amp;fp, \u0026quot;ip and outbound\u0026quot;, 0, 0);\nbpf_dump(\u0026amp;fp, 1);\n\u0026apos;\u0026apos;\u0026apos;\nIts output is:\n\u0026apos;\u0026apos;\u0026apos;\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n\u0026apos;\u0026apos;\u0026apos;\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n\u0026apos;Protocol\u0026apos; field to determine if it\u0026apos;s an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won\u0026apos;t be\nused, so it\u0026apos;s not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[ 44.607039] ------------[ cut here ]------------\n[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[ 44.617726] Call Trace:\n[ 44.617926] \u0026lt;TASK\u0026gt;\n[ 44.619284] userfaultfd_release+0xef/0x1b0\n[ 44.620976] __fput+0x3f9/0xb60\n[ 44.621240] fput_close_sync+0x110/0x210\n[ 44.622222] __x64_sys_close+0x8f/0x120\n[ 44.622530] do_syscall_64+0x5b/0x2f0\n[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all(). Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide. This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation. This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
"id": "OESA-2025-2882",
"modified": "2026-08-06T11:10:00Z",
"published": "2025-12-30T11:10:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2882"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
}
],
"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-42154",
"CVE-2024-49878",
"CVE-2024-56599",
"CVE-2025-21905",
"CVE-2025-21922",
"CVE-2025-23158",
"CVE-2025-23160",
"CVE-2025-37756",
"CVE-2025-37775",
"CVE-2025-37776",
"CVE-2025-37850",
"CVE-2025-37927",
"CVE-2025-38560",
"CVE-2025-39901",
"CVE-2025-39942",
"CVE-2025-40040",
"CVE-2025-40170"
]
}
OESA-2025-2883 (CVE-2024-50269)
Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ( usb: musb: sunxi: Explicitly release USB PHY onexit ) will cause that usb phy @glue->xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue->xceivsunxi_musb_probe() -> devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -> sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()3) register @musb_driver againmusb_probe() -> sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().(CVE-2024-50269)
In the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table 0 65536 linear /dev/sdc 8192 dmsetup resume cdatadmsetup resume cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)
In the Linux kernel, the following vulnerability has been resolved:iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loopof iio_gts_build_avail_scale_table(), the err_free_out will fail to callkfree() each time when i is reduced to 0, so all the per_time_scales[0]and per_time_gains[0] will not be freed, which will cause memory leaks.Fix it by checking if i >= 0.(CVE-2024-53076)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix the warning from __kernel_write_iter
[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280
This patch doesn't allow writing to directory.(CVE-2025-37775)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb_break_all_levII_oplock()
There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)
In the Linux kernel, the following vulnerability has been resolved:
pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line:
do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.
Fixes the following warning:
drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section
ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Evict cache lines during SNP memory validation
An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.
CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.
Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size
This is inspired by the check for data_offset + data_length.(CVE-2025-39942)
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the
BIT() macro.
Note: other VM_ flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_ flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[(CVE-2025-40040)
In the Linux kernel, the following vulnerability has been resolved:
net: use dst_dev_rcu() in sk_setup_caps()
Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().
Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().
ip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-129.0.0.127.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.127.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-129.0.0.127.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:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ( usb: musb: sunxi: Explicitly release USB PHY onexit ) will cause that usb phy @glue-\u0026gt;xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue-\u0026gt;xceivsunxi_musb_probe() -\u0026gt; devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -\u0026gt; sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy()3) register @musb_driver againmusb_probe() -\u0026gt; sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().(CVE-2024-50269)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table 0 65536 linear /dev/sdc 8192 dmsetup resume cdatadmsetup resume cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loopof iio_gts_build_avail_scale_table(), the err_free_out will fail to callkfree() each time when i is reduced to 0, so all the per_time_scales[0]and per_time_gains[0] will not be freed, which will cause memory leaks.Fix it by checking if i \u0026gt;= 0.(CVE-2024-53076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u0026gt;ath10k_core_unregister\n \u2026\u2026\n -\u0026gt;ath10k_core_stop\n -\u0026gt;ath10k_hif_stop\n -\u0026gt;ath10k_sdio_irq_disable\n -\u0026gt;ath10k_hif_power_down\n -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer)\n -\u0026gt;ath10k_core_destroy\n -\u0026gt;ath10k_mac_destroy\n -\u0026gt;ieee80211_free_hw\n -\u0026gt;wiphy_free\n \u2026\u2026\n -\u0026gt;wiphy_dev_release\n -\u0026gt;destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0026apos;t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an \u0026quot;KMSAN: uninit-value\u0026quot; warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n\u0026apos;\u0026apos;\u0026apos;\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, \u0026amp;fp, \u0026quot;ip and outbound\u0026quot;, 0, 0);\nbpf_dump(\u0026amp;fp, 1);\n\u0026apos;\u0026apos;\u0026apos;\nIts output is:\n\u0026apos;\u0026apos;\u0026apos;\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n\u0026apos;\u0026apos;\u0026apos;\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n\u0026apos;Protocol\u0026apos; field to determine if it\u0026apos;s an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won\u0026apos;t be\nused, so it\u0026apos;s not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[ 44.607039] ------------[ cut here ]------------\n[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[ 44.617726] Call Trace:\n[ 44.617926] \u0026lt;TASK\u0026gt;\n[ 44.619284] userfaultfd_release+0xef/0x1b0\n[ 44.620976] __fput+0x3f9/0xb60\n[ 44.621240] fput_close_sync+0x110/0x210\n[ 44.622222] __x64_sys_close+0x8f/0x120\n[ 44.622530] do_syscall_64+0x5b/0x2f0\n[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all(). Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide. This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation. This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
"id": "OESA-2025-2883",
"modified": "2026-08-06T11:10:01Z",
"published": "2025-12-30T11:10:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
}
],
"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-50269",
"CVE-2024-50279",
"CVE-2024-53076",
"CVE-2024-56599",
"CVE-2025-21905",
"CVE-2025-21922",
"CVE-2025-23158",
"CVE-2025-23160",
"CVE-2025-37756",
"CVE-2025-37775",
"CVE-2025-37776",
"CVE-2025-37850",
"CVE-2025-37927",
"CVE-2025-38560",
"CVE-2025-39901",
"CVE-2025-39942",
"CVE-2025-40040",
"CVE-2025-40170"
]
}
OESA-2025-2884 (CVE-2025-22022)
Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().(CVE-2025-23144)
In the Linux kernel, the following vulnerability has been resolved:
mfd: ene-kb3930: Fix a potential NULL pointer dereference
The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference").
This was detected by our static analysis tool.(CVE-2025-23146)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix the warning from __kernel_write_iter
[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280
This patch doesn't allow writing to directory.(CVE-2025-37775)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb_break_all_levII_oplock()
There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)
In the Linux kernel, the following vulnerability has been resolved:
riscv: uprobes: Add missing fence.i after building the XOL buffer
The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions.
This was found running the BPF selftests "test_progs: uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the uprobes tests randomly blew up.(CVE-2025-37822)
In the Linux kernel, the following vulnerability has been resolved:
pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line:
do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.
Fixes the following warning:
drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section
ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix ECVF vports unload on shutdown flow
Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed.
ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports.
kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220
[] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]---(CVE-2025-38109)
In the Linux kernel, the following vulnerability has been resolved:
kernfs: Relax constraint in draining guard
The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfs_should_drain_open_files() is too sensitive -- it may transiently catch those (rightful) callers between kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen Ridong:
kernfs_remove_by_name_ns kernfs_get_active // active=1
__kernfs_remove // active=0x80000002
kernfs_drain ...
wait_event
//waiting (active == 0x80000001)
kernfs_break_active_protection
// active = 0x80000001
// continue
kernfs_unbreak_active_protection
// active = 0x80000002
...
kernfs_should_drain_open_files
// warning occurs
kernfs_put_active
To avoid the false positives (mind panic_on_warn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.)(CVE-2025-38282)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check dce_hwseq before dereferencing it
[WHAT]
hws was checked for null earlier in dce110_blank_stream, indicating hws can be null, and should be checked whenever it is used.
(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)(CVE-2025-38361)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Evict cache lines during SNP memory validation
An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.
CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.
Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent infinite loop in rt6_nlmsg_size()
While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place:
list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); }
This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list.
Restart the loop if f6i->fib6_nsiblings is zero.(CVE-2025-38588)
In the Linux kernel, the following vulnerability has been resolved:
eventpoll: Fix semi-unbounded recursion
Ensure that epoll instances can never form a graph deeper than EP_MAX_NESTS+1 links.
Currently, ep_loop_check_proc() ensures that the graph is loop-free and does some recursion depth checks, but those recursion depth checks don't limit the depth of the resulting tree for two reasons:
- They don't look upwards in the tree.
- If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").
Essentially, the current recursion depth check in ep_loop_check_proc() just serves to prevent it from recursing too deeply while checking for loops.
A more thorough check is done in reverse_path_check() after the new graph edge has already been created; this checks, among other things, that no paths going upwards from any non-epoll file with a length of more than 5 edges exist. However, this check does not apply to non-epoll files.
As a result, it is possible to recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure if deeper recursion is possible; and this may have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion problem").)
To fix it:
- In ep_loop_check_proc(), note the subtree depth of each visited node, and use subtree depths for the total depth calculation even when a subtree has already been visited.
- Add ep_get_upwards_depth_proc() for similarly determining the maximum depth of an upwards walk.
- In ep_loop_check(), use these values to limit the total path length between epoll nodes to EP_MAX_NESTS edges.(CVE-2025-38614)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
rv: Use strings in da monitors tracepoints
Using DA monitors tracepoints with KASAN enabled triggers the following warning:
BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200 trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0
This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed.
Use the __string facilities while defining the tracepoints to avoid reading out of bound memory.(CVE-2025-38636)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()
The function mod_hdcp_hdcp1_create_session() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference.
Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
This is similar to the commit c3e9826a2202 ("drm/amd/display: Add null pointer check for get_first_active_display()").
(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)(CVE-2025-39675)
In the Linux kernel, the following vulnerability has been resolved:
comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()
syzbot reports a KMSAN kernel-infoleak in do_insn_ioctl(). A kernel
buffer is allocated to hold insn->n samples (each of which is an
unsigned int). For some instruction types, insn->n samples are
copied back to user-space, unless an error code is being returned. The
problem is that not all the instruction handlers that need to return
data to userspace fill in the whole insn->n samples, so that there is
an information leak. There is a similar syzbot report for
do_insnlist_ioctl(), although it does not have a reproducer for it at
the time of writing.
One culprit is insn_rw_emulate_bits() which is used as the handler for
INSN_READ or INSN_WRITE instructions for subdevices that do not have
a specific handler for that instruction, but do have an INSN_BITS
handler. For INSN_READ it only fills in at most 1 sample, so if
insn->n is greater than 1, the remaining insn->n - 1 samples copied
to userspace will be uninitialized kernel data.
Another culprit is vm80xx_ai_insn_read() in the "vm80xx" driver. It
never returns an error, even if it fails to fill the buffer.
Fix it in do_insn_ioctl() and do_insnlist_ioctl() by making sure
that uninitialized parts of the allocated buffer are zeroed before
handling each instruction.
Thanks to Arnaud Lecomte for their fix to do_insn_ioctl(). That fix
replaced the call to kmalloc_array() with kcalloc(), but it is not
always necessary to clear the whole buffer.(CVE-2025-39684)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a race when updating an existing write
After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head.
So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().(CVE-2025-39697)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix race with concurrent opens in rename(2)
Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file.
Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target.(CVE-2025-39825)
In the Linux kernel, the following vulnerability has been resolved:
kernfs: Fix UAF in polling when open file is released
A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism:
BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1
psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0+0x188/0x2c0
Allocated by task 1: cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368
Freed by task 8462: cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548
Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure
The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv
epolling disable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epoll_wait kernfs_fop_poll kernfs_get_active = true echo 0 > cgroup.pressure ... cgroup_file_show kernfs_show // inactive kn kernfs_drain_open_files cft->release(of); kfree(ctx); ... kernfs_get_active = false echo 1 > cgroup.pressure kernfs_show kernfs_activate_one(kn); kernfs_fop_poll kernfs_get_active = true cgroup_file_poll psi_trigger_poll // UAF ... end: close(fd)
To address this issue, introduce kernfs_get_active_of() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfs_get_active() with kernfs_get_active_of() to prevent further operations on released file descriptors.(CVE-2025-39881)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size
This is inspired by the check for data_offset + data_length.(CVE-2025-39942)
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the
BIT() macro.
Note: other VM_ flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_ flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[(CVE-2025-40040)
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: fix uninit-value in squashfs_get_parent
Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.
This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory.
Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field.
unsigned int parent_ino = squashfs_i(inode)->parent;
Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access.
The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned.
Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0.(CVE-2025-40049)
In the Linux kernel, the following vulnerability has been resolved:
net: use dst_dev_rcu() in sk_setup_caps()
Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().
Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().
ip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"perf-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-129.0.0.127.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"perf-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-129.0.0.127.oe2403sp2"
}
],
"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\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().(CVE-2025-23144)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: ene-kb3930: Fix a potential NULL pointer dereference\n\nThe off_gpios could be NULL. Add missing check in the kb3930_probe().\nThis is similar to the issue fixed in commit b1ba8bcb2d1f\n(\u0026quot;backlight: hx8357: Fix potential NULL pointer dereference\u0026quot;).\n\nThis was detected by our static analysis tool.(CVE-2025-23146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: uprobes: Add missing fence.i after building the XOL buffer\n\nThe XOL (execute out-of-line) buffer is used to single-step the\nreplaced instruction(s) for uprobes. The RISC-V port was missing a\nproper fence.i (i$ flushing) after constructing the XOL buffer, which\ncan result in incorrect execution of stale/broken instructions.\n\nThis was found running the BPF selftests \u0026quot;test_progs:\nuprobe_autoattach, attach_probe\u0026quot; on the Spacemit K1/X60, where the\nuprobes tests randomly blew up.(CVE-2025-37822)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix ECVF vports unload on shutdown flow\n\nFix shutdown flow UAF when a virtual function is created on the embedded\nchip (ECVF) of a BlueField device. In such case the vport acl ingress\ntable is not properly destroyed.\n\nECVF functionality is independent of ecpf_vport_exists capability and\nthus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not\ntest it when enabling/disabling ECVF vports.\n\nkernel log:\n[] refcount_t: underflow; use-after-free.\n[] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28\n refcount_warn_saturate+0x124/0x220\n----------------\n[] Call trace:\n[] refcount_warn_saturate+0x124/0x220\n[] tree_put_node+0x164/0x1e0 [mlx5_core]\n[] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core]\n[] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core]\n[] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core]\n[] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core]\n[] esw_vport_cleanup+0x64/0x90 [mlx5_core]\n[] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core]\n[] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core]\n[] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core]\n[] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core]\n[] mlx5_sriov_detach+0x40/0x50 [mlx5_core]\n[] mlx5_unload+0x40/0xc4 [mlx5_core]\n[] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core]\n[] mlx5_unload_one+0x3c/0x60 [mlx5_core]\n[] shutdown+0x7c/0xa4 [mlx5_core]\n[] pci_device_shutdown+0x3c/0xa0\n[] device_shutdown+0x170/0x340\n[] __do_sys_reboot+0x1f4/0x2a0\n[] __arm64_sys_reboot+0x2c/0x40\n[] invoke_syscall+0x78/0x100\n[] el0_svc_common.constprop.0+0x54/0x184\n[] do_el0_svc+0x30/0xac\n[] el0_svc+0x48/0x160\n[] el0t_64_sync_handler+0xa4/0x12c\n[] el0t_64_sync+0x1a4/0x1a8\n[] --[ end trace 9c4601d68c70030e ]---(CVE-2025-38109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: Relax constraint in draining guard\n\nThe active reference lifecycle provides the break/unbreak mechanism but\nthe active reference is not truly active after unbreak -- callers don\u0026apos;t\nuse it afterwards but it\u0026apos;s important for proper pairing of kn-\u0026gt;active\ncounting. Assuming this mechanism is in place, the WARN check in\nkernfs_should_drain_open_files() is too sensitive -- it may transiently\ncatch those (rightful) callers between\nkernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen\nRidong:\n\n\tkernfs_remove_by_name_ns\tkernfs_get_active // active=1\n\t__kernfs_remove\t\t\t\t\t // active=0x80000002\n\tkernfs_drain\t\t\t...\n\twait_event\n\t//waiting (active == 0x80000001)\n\t\t\t\t\tkernfs_break_active_protection\n\t\t\t\t\t// active = 0x80000001\n\t// continue\n\t\t\t\t\tkernfs_unbreak_active_protection\n\t\t\t\t\t// active = 0x80000002\n\t...\n\tkernfs_should_drain_open_files\n\t// warning occurs\n\t\t\t\t\tkernfs_put_active\n\nTo avoid the false positives (mind panic_on_warn) remove the check altogether.\n(This is meant as quick fix, I think active reference break/unbreak may be\nsimplified with larger rework.)(CVE-2025-38282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check dce_hwseq before dereferencing it\n\n[WHAT]\n\nhws was checked for null earlier in dce110_blank_stream, indicating hws\ncan be null, and should be checked whenever it is used.\n\n(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)(CVE-2025-38361)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent infinite loop in rt6_nlmsg_size()\n\nWhile testing prior patch, I was able to trigger\nan infinite loop in rt6_nlmsg_size() in the following place:\n\nlist_for_each_entry_rcu(sibling, \u0026amp;f6i-\u0026gt;fib6_siblings,\n\t\t\tfib6_siblings) {\n\trt6_nh_nlmsg_size(sibling-\u0026gt;fib6_nh, \u0026amp;nexthop_len);\n}\n\nThis is because fib6_del_route() and fib6_add_rt2node()\nuses list_del_rcu(), which can confuse rcu readers,\nbecause they might no longer see the head of the list.\n\nRestart the loop if f6i-\u0026gt;fib6_nsiblings is zero.(CVE-2025-38588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: Fix semi-unbounded recursion\n\nEnsure that epoll instances can never form a graph deeper than\nEP_MAX_NESTS+1 links.\n\nCurrently, ep_loop_check_proc() ensures that the graph is loop-free and\ndoes some recursion depth checks, but those recursion depth checks don\u0026apos;t\nlimit the depth of the resulting tree for two reasons:\n\n - They don\u0026apos;t look upwards in the tree.\n - If there are multiple downwards paths of different lengths, only one of\n the paths is actually considered for the depth check since commit\n 28d82dc1c4ed (\u0026quot;epoll: limit paths\u0026quot;).\n\nEssentially, the current recursion depth check in ep_loop_check_proc() just\nserves to prevent it from recursing too deeply while checking for loops.\n\nA more thorough check is done in reverse_path_check() after the new graph\nedge has already been created; this checks, among other things, that no\npaths going upwards from any non-epoll file with a length of more than 5\nedges exist. However, this check does not apply to non-epoll files.\n\nAs a result, it is possible to recurse to a depth of at least roughly 500,\ntested on v6.15. (I am unsure if deeper recursion is possible; and this may\nhave changed with commit 8c44dac8add7 (\u0026quot;eventpoll: Fix priority inversion\nproblem\u0026quot;).)\n\nTo fix it:\n\n1. In ep_loop_check_proc(), note the subtree depth of each visited node,\nand use subtree depths for the total depth calculation even when a subtree\nhas already been visited.\n2. Add ep_get_upwards_depth_proc() for similarly determining the maximum\ndepth of an upwards walk.\n3. In ep_loop_check(), use these values to limit the total path length\nbetween epoll nodes to EP_MAX_NESTS edges.(CVE-2025-38614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrv: Use strings in da monitors tracepoints\n\nUsing DA monitors tracepoints with KASAN enabled triggers the following\nwarning:\n\n BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0\n Read of size 32 at addr ffffffffaada8980 by task ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n [...]\n do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0\n ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10\n ? trace_event_sncid+0x83/0x200\n trace_event_sncid+0x163/0x200\n [...]\n The buggy address belongs to the variable:\n automaton_snep+0x4e0/0x5e0\n\nThis is caused by the tracepoints reading 32 bytes __array instead of\n__string from the automata definition. Such strings are literals and\nreading 32 bytes ends up in out of bound memory accesses (e.g. the next\nautomaton\u0026apos;s data in this case).\nThe error is harmless as, while printing the string, we stop at the null\nterminator, but it should still be fixed.\n\nUse the __string facilities while defining the tracepoints to avoid\nreading out of bound memory.(CVE-2025-38636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()\n\nThe function mod_hdcp_hdcp1_create_session() calls the function\nget_first_active_display(), but does not check its return value.\nThe return value is a null pointer if the display list is empty.\nThis will lead to a null pointer dereference.\n\nAdd a null pointer check for get_first_active_display() and return\nMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.\n\nThis is similar to the commit c3e9826a2202\n(\u0026quot;drm/amd/display: Add null pointer check for get_first_active_display()\u0026quot;).\n\n(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)(CVE-2025-39675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()\n\nsyzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel\nbuffer is allocated to hold `insn-\u0026gt;n` samples (each of which is an\n`unsigned int`). For some instruction types, `insn-\u0026gt;n` samples are\ncopied back to user-space, unless an error code is being returned. The\nproblem is that not all the instruction handlers that need to return\ndata to userspace fill in the whole `insn-\u0026gt;n` samples, so that there is\nan information leak. There is a similar syzbot report for\n`do_insnlist_ioctl()`, although it does not have a reproducer for it at\nthe time of writing.\n\nOne culprit is `insn_rw_emulate_bits()` which is used as the handler for\n`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have\na specific handler for that instruction, but do have an `INSN_BITS`\nhandler. For `INSN_READ` it only fills in at most 1 sample, so if\n`insn-\u0026gt;n` is greater than 1, the remaining `insn-\u0026gt;n - 1` samples copied\nto userspace will be uninitialized kernel data.\n\nAnother culprit is `vm80xx_ai_insn_read()` in the \u0026quot;vm80xx\u0026quot; driver. It\nnever returns an error, even if it fails to fill the buffer.\n\nFix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure\nthat uninitialized parts of the allocated buffer are zeroed before\nhandling each instruction.\n\nThanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix\nreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is not\nalways necessary to clear the whole buffer.(CVE-2025-39684)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a race when updating an existing write\n\nAfter nfs_lock_and_join_requests() tests for whether the request is\nstill attached to the mapping, nothing prevents a call to\nnfs_inode_remove_request() from succeeding until we actually lock the\npage group.\nThe reason is that whoever called nfs_inode_remove_request() doesn\u0026apos;t\nnecessarily have a lock on the page group head.\n\nSo in order to avoid races, let\u0026apos;s take the page group lock earlier in\nnfs_lock_and_join_requests(), and hold it across the removal of the\nrequest in nfs_inode_remove_request().(CVE-2025-39697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix race with concurrent opens in rename(2)\n\nBesides sending the rename request to the server, the rename process\nalso involves closing any deferred close, waiting for outstanding I/O\nto complete as well as marking all existing open handles as deleted to\nprevent them from deferring closes, which increases the race window\nfor potential concurrent opens on the target file.\n\nFix this by unhashing the dentry in advance to prevent any concurrent\nopens on the target.(CVE-2025-39825)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: Fix UAF in polling when open file is released\n\nA use-after-free (UAF) vulnerability was identified in the PSI (Pressure\nStall Information) monitoring mechanism:\n\nBUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140\nRead of size 8 at addr ffff3de3d50bd308 by task systemd/1\n\npsi_trigger_poll+0x3c/0x140\ncgroup_pressure_poll+0x70/0xa0\ncgroup_file_poll+0x8c/0x100\nkernfs_fop_poll+0x11c/0x1c0\nep_item_poll.isra.0+0x188/0x2c0\n\nAllocated by task 1:\ncgroup_file_open+0x88/0x388\nkernfs_fop_open+0x73c/0xaf0\ndo_dentry_open+0x5fc/0x1200\nvfs_open+0xa0/0x3f0\ndo_open+0x7e8/0xd08\npath_openat+0x2fc/0x6b0\ndo_filp_open+0x174/0x368\n\nFreed by task 8462:\ncgroup_file_release+0x130/0x1f8\nkernfs_drain_open_files+0x17c/0x440\nkernfs_drain+0x2dc/0x360\nkernfs_show+0x1b8/0x288\ncgroup_file_show+0x150/0x268\ncgroup_pressure_write+0x1dc/0x340\ncgroup_file_write+0x274/0x548\n\nReproduction Steps:\n1. Open test/cpu.pressure and establish epoll monitoring\n2. Disable monitoring: echo 0 \u0026gt; test/cgroup.pressure\n3. Re-enable monitoring: echo 1 \u0026gt; test/cgroup.pressure\n\nThe race condition occurs because:\n1. When cgroup.pressure is disabled (echo 0 \u0026gt; cgroup.pressure), it:\n - Releases PSI triggers via cgroup_file_release()\n - Frees of-\u0026gt;priv through kernfs_drain_open_files()\n2. While epoll still holds reference to the file and continues polling\n3. Re-enabling (echo 1 \u0026gt; cgroup.pressure) accesses freed of-\u0026gt;priv\n\nepolling\t\t\tdisable/enable cgroup.pressure\nfd=open(cpu.pressure)\nwhile(1)\n...\nepoll_wait\nkernfs_fop_poll\nkernfs_get_active = true\techo 0 \u0026gt; cgroup.pressure\n...\t\t\t\tcgroup_file_show\n\t\t\t\tkernfs_show\n\t\t\t\t// inactive kn\n\t\t\t\tkernfs_drain_open_files\n\t\t\t\tcft-\u0026gt;release(of);\n\t\t\t\tkfree(ctx);\n\t\t\t\t...\nkernfs_get_active = false\n\t\t\t\techo 1 \u0026gt; cgroup.pressure\n\t\t\t\tkernfs_show\n\t\t\t\tkernfs_activate_one(kn);\nkernfs_fop_poll\nkernfs_get_active = true\ncgroup_file_poll\npsi_trigger_poll\n// UAF\n...\nend: close(fd)\n\nTo address this issue, introduce kernfs_get_active_of() for kernfs open\nfiles to obtain active references. This function will fail if the open file\nhas been released. Replace kernfs_get_active() with kernfs_get_active_of()\nto prevent further operations on released file descriptors.(CVE-2025-39881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[ 44.607039] ------------[ cut here ]------------\n[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[ 44.617726] Call Trace:\n[ 44.617926] \u0026lt;TASK\u0026gt;\n[ 44.619284] userfaultfd_release+0xef/0x1b0\n[ 44.620976] __fput+0x3f9/0xb60\n[ 44.621240] fput_close_sync+0x110/0x210\n[ 44.622222] __x64_sys_close+0x8f/0x120\n[ 44.622530] do_syscall_64+0x5b/0x2f0\n[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all(). Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide. This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation. This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: fix uninit-value in squashfs_get_parent\n\nSyzkaller reports a \u0026quot;KMSAN: uninit-value in squashfs_get_parent\u0026quot; bug.\n\nThis is caused by open_by_handle_at() being called with a file handle\ncontaining an invalid parent inode number. In particular the inode number\nis that of a symbolic link, rather than a directory.\n\nSquashfs_get_parent() gets called with that symbolic link inode, and\naccesses the parent member field.\n\n\tunsigned int parent_ino = squashfs_i(inode)-\u0026gt;parent;\n\nBecause non-directory inodes in Squashfs do not have a parent value, this\nis uninitialised, and this causes an uninitialised value access.\n\nThe fix is to initialise parent with the invalid inode 0, which will cause\nan EINVAL error to be returned.\n\nRegular inodes used to share the parent field with the block_list_start\nfield. This is removed in this commit to enable the parent field to\ncontain the invalid inode number 0.(CVE-2025-40049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
"id": "OESA-2025-2884",
"modified": "2026-08-06T11:10:01Z",
"published": "2025-12-30T11:10:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2884"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23144"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23146"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37822"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38109"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38361"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38588"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38614"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38636"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39684"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39825"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40049"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
}
],
"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-2025-22022",
"CVE-2025-22039",
"CVE-2025-23144",
"CVE-2025-23146",
"CVE-2025-23158",
"CVE-2025-23160",
"CVE-2025-37756",
"CVE-2025-37775",
"CVE-2025-37776",
"CVE-2025-37822",
"CVE-2025-37850",
"CVE-2025-37927",
"CVE-2025-38109",
"CVE-2025-38282",
"CVE-2025-38361",
"CVE-2025-38560",
"CVE-2025-38588",
"CVE-2025-38614",
"CVE-2025-38617",
"CVE-2025-38636",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-39675",
"CVE-2025-39684",
"CVE-2025-39697",
"CVE-2025-39825",
"CVE-2025-39881",
"CVE-2025-39901",
"CVE-2025-39942",
"CVE-2025-40040",
"CVE-2025-40049",
"CVE-2025-40170"
]
}
OPENSUSE-SU-2026:20145-1
Vulnerability from csaf_opensuse - Published: 2026-02-02 11:54 - Updated: 2026-09-30 15:57RHSA-2026:2212
Vulnerability from csaf_opensuse - Published: 2026-02-09 00:00 - Updated: 2026-09-16 18:19RHSA-2026:2264
Vulnerability from csaf_opensuse - Published: 2026-02-09 00:00 - Updated: 2026-09-16 18:28RHSA-2026:1690
Vulnerability from csaf_redhat - Published: 2026-02-02 10:10 - Updated: 2026-08-27 07:57In the Linux kernel, the following vulnerability has been resolved: net: use dst_dev_rcu() in sk_setup_caps() Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size(). Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward(). ip4_dst_hoplimit() can use dst_dev_net_rcu().
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.