Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-38154 (GCVE-0-2025-38154)
Vulnerability from cvelistv5 – Published: 2025-07-03 08:35 – Updated: 2026-08-05 11:59| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
4959ffc65a0e94f8acaac20deac49f89e6ded52d , < 4edb40b05cb6a261775abfd8046804ca139a5546
(git)
Affected: 5eabdf17fed2ad41b836bb4055ec36d95e512c50 , < b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9 (git) Affected: e946428439a0d2079959f5603256ac51b6047017 , < 4c6fa65ab2aec7df94809478c8d28ef38676a1b7 (git) Affected: 4b4647add7d3c8530493f7247d11e257ee425bf0 , < 15c0250dae3b48a398447d2b364603821ed4ed90 (git) Affected: 4b4647add7d3c8530493f7247d11e257ee425bf0 , < 7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987 (git) Affected: 4b4647add7d3c8530493f7247d11e257ee425bf0 , < 8259eb0e06d8f64c700f5fbdb28a5c18e10de291 (git) Affected: 3627605de498639a3c586c8684d12c89cba11073 (git) Affected: 5.15.162 , < 5.15.186 (semver) Affected: 6.1.95 , < 6.1.142 (semver) Affected: 6.6.35 , < 6.6.94 (semver) Affected: 6.9.6 , < 6.10 (semver) |
guessed | |
| Linux | Linux |
Affected:
6.10
Unaffected: 0 , < 6.10 (semver) Unaffected: 5.15.186 , ≤ 5.15.* (semver) Unaffected: 6.1.142 , ≤ 6.1.* (semver) Unaffected: 6.6.94 , ≤ 6.6.* (semver) Unaffected: 6.12.34 , ≤ 6.12.* (semver) Unaffected: 6.15.3 , ≤ 6.15.* (semver) Unaffected: 6.16 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T17:34:44.423Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/core/skmsg.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4edb40b05cb6a261775abfd8046804ca139a5546",
"status": "affected",
"version": "4959ffc65a0e94f8acaac20deac49f89e6ded52d",
"versionType": "git"
},
{
"lessThan": "b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9",
"status": "affected",
"version": "5eabdf17fed2ad41b836bb4055ec36d95e512c50",
"versionType": "git"
},
{
"lessThan": "4c6fa65ab2aec7df94809478c8d28ef38676a1b7",
"status": "affected",
"version": "e946428439a0d2079959f5603256ac51b6047017",
"versionType": "git"
},
{
"lessThan": "15c0250dae3b48a398447d2b364603821ed4ed90",
"status": "affected",
"version": "4b4647add7d3c8530493f7247d11e257ee425bf0",
"versionType": "git"
},
{
"lessThan": "7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987",
"status": "affected",
"version": "4b4647add7d3c8530493f7247d11e257ee425bf0",
"versionType": "git"
},
{
"lessThan": "8259eb0e06d8f64c700f5fbdb28a5c18e10de291",
"status": "affected",
"version": "4b4647add7d3c8530493f7247d11e257ee425bf0",
"versionType": "git"
},
{
"status": "affected",
"version": "3627605de498639a3c586c8684d12c89cba11073",
"versionType": "git"
},
{
"lessThan": "5.15.186",
"status": "affected",
"version": "5.15.162",
"versionType": "semver"
},
{
"lessThan": "6.1.142",
"status": "affected",
"version": "6.1.95",
"versionType": "semver"
},
{
"lessThan": "6.6.94",
"status": "affected",
"version": "6.6.35",
"versionType": "semver"
},
{
"lessThan": "6.10",
"status": "affected",
"version": "6.9.6",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/core/skmsg.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.10"
},
{
"lessThan": "6.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.186",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.142",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.94",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.34",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.186",
"versionStartIncluding": "5.15.162",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.142",
"versionStartIncluding": "6.1.95",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.94",
"versionStartIncluding": "6.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.34",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.3",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16",
"versionStartIncluding": "6.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "6.9.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u003esk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0027\u0027\u0027\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u003erelease() -\u003e sock_map_close()\n sk_socket-\u003eops = NULL\n free(socket)\n sock-\u003eops-\u003esendmsg\n ^\n panic here\n\u0027\u0027\u0027\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0027\u0027\u0027\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u003c=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026psock-\u003ework); \u003c=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0027\u0027\u0027\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0027t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0027\u0027\u0027\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u003cTASK\u003e\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0027\u0027\u0027"
}
],
"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 race is closed by a local `close(fd)` on a sockmap-enrolled socket concurrent with the BPF backlog worker; while remote peer data drives the backlog side, the attacker must be local to control the socket lifetime. BPF/sockmap is Local per kernel scoring guidance.\nAC:L - The attacker controls both sides of the race \u2014 it generates the redirected traffic that schedules `sk_psock_backlog()` and picks the `close()` timing \u2014 and can repeat the attempt in a tight loop until it wins. No condition outside its influence is required.\nPR:L - An unprivileged local process suffices in the real deployments of this feature (Cilium/Istio sockops redirect, BPF-token-delegated containers), where a privileged agent enrols workload sockets into the sockmap and the attacker only needs to send/redirect data and close its own fd.\nUI:N - No victim action is needed; the attacker drives both the traffic and the close from its own process.\nS:U - The use-after-free and any resulting corruption remain within the kernel\u0027s own security authority, with no VM, IOMMU, or sandbox boundary crossed.\nC:H - Use-after-free on `struct socket` \u2014 the freed object can be resprayed from `sock_inode_cachep`, causing redirected payload to be transmitted through a stale/attacker-influenced socket and permitting kernel memory disclosure.\nI:H - `security_socket_sendmsg()` and `READ_ONCE(sock-\u003eops)-\u003esendmsg` dereference and indirect-call through a pointer loaded from freed memory, giving a control-flow hijack primitive once the freed `struct socket` is reclaimed with attacker-groomed contents.\nA:H - The maintainer reproduced a general-protection fault in `sock_sendmsg()` from the `sk_psock_backlog` workqueue; the NULLed `sock-\u003eops` alone guarantees a fatal kernel oops in worker context."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:59:54.410Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546"
},
{
"url": "https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9"
},
{
"url": "https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7"
},
{
"url": "https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90"
},
{
"url": "https://git.kernel.org/stable/c/7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987"
},
{
"url": "https://git.kernel.org/stable/c/8259eb0e06d8f64c700f5fbdb28a5c18e10de291"
}
],
"title": "bpf, sockmap: Avoid using sk_socket after free when sending",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-38154",
"datePublished": "2025-07-03T08:35:57.188Z",
"dateReserved": "2025-04-16T04:51:23.990Z",
"dateUpdated": "2026-08-05T11:59:54.410Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-38154",
"date": "2026-09-17",
"epss": "0.00164",
"percentile": "0.06087"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2025-38154\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-07-03T09:15:30.363\",\"lastModified\":\"2026-07-30T06:22:55.597\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf, sockmap: Avoid using sk_socket after free when sending\\n\\nThe sk-\u003esk_socket is not locked or referenced in backlog thread, and\\nduring the call to skb_send_sock(), there is a race condition with\\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\\nwill be affected.\\n\\nRace conditions:\\n\u0027\u0027\u0027\\nCPU0 CPU1\\n\\nbacklog::skb_send_sock\\n sendmsg_unlocked\\n sock_sendmsg\\n sock_sendmsg_nosec\\n close(fd):\\n ...\\n ops-\u003erelease() -\u003e sock_map_close()\\n sk_socket-\u003eops = NULL\\n free(socket)\\n sock-\u003eops-\u003esendmsg\\n ^\\n panic here\\n\u0027\u0027\u0027\\n\\nThe ref of psock become 0 after sock_map_close() executed.\\n\u0027\u0027\u0027\\nvoid sock_map_close()\\n{\\n ...\\n if (likely(psock)) {\\n ...\\n // !! here we remove psock and the ref of psock become 0\\n sock_map_remove_links(sk, psock)\\n psock = sk_psock_get(sk);\\n if (unlikely(!psock))\\n goto no_psock; \u003c=== Control jumps here via goto\\n ...\\n cancel_delayed_work_sync(\u0026psock-\u003ework); \u003c=== not executed\\n sk_psock_put(sk, psock);\\n ...\\n}\\n\u0027\u0027\u0027\\n\\nBased on the fact that we already wait for the workqueue to finish in\\nsock_map_close() if psock is held, we simply increase the psock\\nreference count to avoid race conditions.\\n\\nWith this patch, if the backlog thread is running, sock_map_close() will\\nwait for the backlog thread to complete and cancel all pending work.\\n\\nIf no backlog running, any pending work that hasn\u0027t started by then will\\nfail when invoked by sk_psock_get(), as the psock reference count have\\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\\ncancel_delayed_work_sync().\\n\\nIn summary, we require synchronization to coordinate the backlog thread\\nand close() thread.\\n\\nThe panic I catched:\\n\u0027\u0027\u0027\\nWorkqueue: events sk_psock_backlog\\nRIP: 0010:sock_sendmsg+0x21d/0x440\\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\\n...\\nCall Trace:\\n \u003cTASK\u003e\\n ? die_addr+0x40/0xa0\\n ? exc_general_protection+0x14c/0x230\\n ? asm_exc_general_protection+0x26/0x30\\n ? sock_sendmsg+0x21d/0x440\\n ? sock_sendmsg+0x3e0/0x440\\n ? __pfx_sock_sendmsg+0x10/0x10\\n __skb_send_sock+0x543/0xb70\\n sk_psock_backlog+0x247/0xb80\\n...\\n\u0027\u0027\u0027\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Evite usar sk_socket despu\u00e9s de liberar al enviar El sk-\u0026gt;sk_socket no est\u00e1 bloqueado o referenciado en el hilo del backlog, y durante la llamada a skb_send_sock(), hay una condici\u00f3n de ejecuci\u00f3n con la liberaci\u00f3n de sk_socket. Todos los tipos de sockets (tcp/udp/unix/vsock) se ver\u00e1n afectados. Condiciones de ejecuciones: \u0027\u0027\u0027 CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops-\u0026gt;release() -\u0026gt; sock_map_close() sk_socket-\u0026gt;ops = NULL free(socket) sock-\u0026gt;ops-\u0026gt;sendmsg ^ p\u00e1nico aqu\u00ed \u0027\u0027\u0027 La referencia de psock se convierte en 0 despu\u00e9s de ejecutar sock_map_close(). \u0027\u0027\u0027 void sock_map_close() { ... if (likely(psock)) { ... // !! aqu\u00ed eliminamos psock y la referencia de psock se convierte en 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; \u0026lt;=== El control salta aqu\u00ed mediante goto ... cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== no se ejecuta sk_psock_put(sk, psock); ... } \u0027\u0027\u0027 Bas\u00e1ndonos en el hecho de que ya esperamos a que finalice la cola de trabajo en sock_map_close() si psock est\u00e1 retenido, simplemente aumentamos el recuento de referencias de psock para evitar condiciones de ejecuci\u00f3n. Con este parche, si el hilo de la lista de tareas pendientes se est\u00e1 ejecutando, sock_map_close() esperar\u00e1 a que se complete el hilo de la lista de tareas pendientes y cancelar\u00e1 todo el trabajo pendiente. Si no hay trabajos pendientes en ejecuci\u00f3n, cualquier trabajo pendiente que no haya comenzado para entonces fallar\u00e1 al ser invocado por sk_psock_get(), ya que el recuento de referencias de psock se ha puesto a cero, y sk_psock_drop() cancelar\u00e1 todos los trabajos mediante cancel_delayed_work_sync(). En resumen, necesitamos sincronizaci\u00f3n para coordinar el hilo de trabajo pendiente y el hilo de cierre. El p\u00e1nico que me entr\u00f3: \u0027\u0027\u0027 Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... \u0027\u0027\u0027 \"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"net/core/skmsg.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4959ffc65a0e94f8acaac20deac49f89e6ded52d\",\"lessThan\":\"4edb40b05cb6a261775abfd8046804ca139a5546\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"5eabdf17fed2ad41b836bb4055ec36d95e512c50\",\"lessThan\":\"b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"e946428439a0d2079959f5603256ac51b6047017\",\"lessThan\":\"4c6fa65ab2aec7df94809478c8d28ef38676a1b7\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4b4647add7d3c8530493f7247d11e257ee425bf0\",\"lessThan\":\"15c0250dae3b48a398447d2b364603821ed4ed90\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4b4647add7d3c8530493f7247d11e257ee425bf0\",\"lessThan\":\"7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4b4647add7d3c8530493f7247d11e257ee425bf0\",\"lessThan\":\"8259eb0e06d8f64c700f5fbdb28a5c18e10de291\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3627605de498639a3c586c8684d12c89cba11073\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"5.15.162\",\"lessThan\":\"5.15.186\",\"versionType\":\"semver\",\"status\":\"affected\"},{\"version\":\"6.1.95\",\"lessThan\":\"6.1.142\",\"versionType\":\"semver\",\"status\":\"affected\"},{\"version\":\"6.6.35\",\"lessThan\":\"6.6.94\",\"versionType\":\"semver\",\"status\":\"affected\"},{\"version\":\"6.9.6\",\"lessThan\":\"6.10\",\"versionType\":\"semver\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"net/core/skmsg.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"6.10\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.10\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.186\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.142\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.94\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.34\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.15.3\",\"lessThanOrEqual\":\"6.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.16\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.15.162\",\"versionEndExcluding\":\"5.15.186\",\"matchCriteriaId\":\"D435B53D-0FAA-4FE8-A253-D3BB51FB33D6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.1.95\",\"versionEndExcluding\":\"6.1.142\",\"matchCriteriaId\":\"09E3982E-A817-487E-AF93-05C0CE745E45\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.6.35\",\"versionEndExcluding\":\"6.6.94\",\"matchCriteriaId\":\"B5F01BA1-187F-4D06-B1A6-D43397B8DEBD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.9.6\",\"versionEndExcluding\":\"6.10\",\"matchCriteriaId\":\"AEE76B76-CD40-4103-8E82-768D583AB8A8\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.10.1\",\"versionEndExcluding\":\"6.12.34\",\"matchCriteriaId\":\"FB4B0709-0132-4A32-8703-77BDD84FDF62\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13\",\"versionEndExcluding\":\"6.15.3\",\"matchCriteriaId\":\"0541C761-BD5E-4C1A-8432-83B375D7EB92\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:-:*:*:*:*:*:*\",\"matchCriteriaId\":\"9EA80796-744E-45F5-8632-2AB4F7889FCD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"331C2F14-12C7-45D5-893D-8C52EE38EA10\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"3173713D-909A-4DD3-9DD4-1E171EB057EE\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"79F18AFA-40F7-43F0-BA30-7BDB65F918B9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"BD973AA4-A789-49BD-8D57-B2846935D3C7\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc6:*:*:*:*:*:*\",\"matchCriteriaId\":\"8F3E9E0C-AC3E-4967-AF80-6483E8AB0078\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.10:rc7:*:*:*:*:*:*\",\"matchCriteriaId\":\"11AF4CB9-F697-4EA4-8903-8F9417EFDA8E\"}]}]},{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"FA6FEEC2-9F11-4643-8827-749718254FED\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/8259eb0e06d8f64c700f5fbdb28a5c18e10de291\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}",
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-07-30T09:23:28+00:00",
"cve": "CVE-2025-38154",
"id": "CVE-2025-38154",
"initial_release_date": "2025-07-03T00:00:00+00:00",
"product_status:fixed": "1256",
"product_status:known_affected": "184",
"product_status:known_not_affected": "90",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Linux kernel: Use-after-free in BPF sockmap can lead to denial of service and privilege escalation",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-38154.json",
"version": "3"
}
}
}
CERTFR-2026-AVI-0423
Vulnerability from certfr_avis - Published: 2026-04-10 - Updated: 2026-04-10
De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
None| Vendor | Product | Description | ||
|---|---|---|---|---|
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 10 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 9 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.2 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian 9 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 10 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.0 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian 10 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.0 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.2 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.0 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.6 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for IBM z Systems 10 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.0 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.2 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.0 s390x | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.6 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.0 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian 8 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems 8 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - TUS 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.6 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - TUS 8.8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.0 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 8 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.0 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 9 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.6 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 10 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian 10 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 8.4 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 8.10 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Real Time for NFV 8 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.4 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.6 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 9.2 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.0 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 8 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.6 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 8.10 s390x | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian 9 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.6 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.6 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.0 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.8 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems 9 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 8.10 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.0 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux Server - AUS 8.2 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for x86_64 9 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Real Time 8 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.6 ppc64le | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.6 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.2 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for ARM 64 10 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for IBM z Systems 10 s390x | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.0 aarch64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.6 x86_64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for ARM 64 9 aarch64 | ||
| Red Hat | N/A | Red Hat CodeReady Linux Builder for IBM z Systems 9 s390x | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.0 x86_64 | ||
| Red Hat | N/A | Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 8.10 x86_64 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Red Hat Enterprise Linux for x86_64 10 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 9.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 9 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.2 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 9 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 10 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 10.0 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 10 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Update Support 10.0 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.2 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - 4 years of updates 10.0 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.6 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems 10 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - 4 years of support 10.0 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 9.2 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 10.0 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 9.6 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.2 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 10.0 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian 8 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 8 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - TUS 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 9.6 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - TUS 8.8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 - Extended Update Support 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 10.0 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 8 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 10.0 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 9 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Update Support 9.6 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 9.2 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 10 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 8.8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 10 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 8.4 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 8.10 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time for NFV 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.4 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.6 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 9.2 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.0 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 8 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian - Extended Update Support 9.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 9.6 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.2 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Life Cycle 8.10 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 9 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 9.6 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems - Extended Update Support 9.6 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - Extended Update Support 10.0 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server for Power LE - Update Services for SAP Solutions 8.8 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 9 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - Extended Life Cycle 8.10 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 - 4 years of updates 10.0 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux Server - AUS 8.2 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for x86_64 9 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Real Time 8 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for Power, little endian 8 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for Power, little endian - Extended Life Cycle 9.6 ppc64le",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Update Services for SAP Solutions 9.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 9.2 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for ARM 64 10 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems - 4 years of updates 9.2 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for IBM z Systems 10 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 - Extended Update Support 10.0 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support Extension 8.6 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for ARM 64 9 aarch64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat CodeReady Linux Builder for IBM z Systems 9 s390x",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Update Support 10.0 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
},
{
"description": "Red Hat Enterprise Linux for x86_64 - Extended Life Cycle 8.10 x86_64",
"product": {
"name": "N/A",
"vendor": {
"name": "Red Hat",
"scada": false
}
}
}
],
"affected_systems_content": null,
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-40064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40064"
},
{
"name": "CVE-2024-26984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26984"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2026-23210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23210"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2026-23191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23191"
},
{
"name": "CVE-2021-4460",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4460"
},
{
"name": "CVE-2025-38206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38206"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2026-23193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23193"
},
{
"name": "CVE-2025-40168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40168"
},
{
"name": "CVE-2026-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23144"
},
{
"name": "CVE-2025-68811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68811"
},
{
"name": "CVE-2022-49674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49674"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2026-23171",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23171"
},
{
"name": "CVE-2025-38180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38180"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-71238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71238"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
}
],
"initial_release_date": "2026-04-10T00:00:00",
"last_revision_date": "2026-04-10T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0423",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-04-10T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de Red Hat. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de Red Hat",
"vendor_advisories": [
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6954",
"url": "https://access.redhat.com/errata/RHSA-2026:6954"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6632",
"url": "https://access.redhat.com/errata/RHSA-2026:6632"
},
{
"published_at": "2026-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6940",
"url": "https://access.redhat.com/errata/RHSA-2026:6940"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6571",
"url": "https://access.redhat.com/errata/RHSA-2026:6571"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6570",
"url": "https://access.redhat.com/errata/RHSA-2026:6570"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:7100",
"url": "https://access.redhat.com/errata/RHSA-2026:7100"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6948",
"url": "https://access.redhat.com/errata/RHSA-2026:6948"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6961",
"url": "https://access.redhat.com/errata/RHSA-2026:6961"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6572",
"url": "https://access.redhat.com/errata/RHSA-2026:6572"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:7003",
"url": "https://access.redhat.com/errata/RHSA-2026:7003"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6986",
"url": "https://access.redhat.com/errata/RHSA-2026:6986"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6953",
"url": "https://access.redhat.com/errata/RHSA-2026:6953"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Red Hat RHSA-2026:6692",
"url": "https://access.redhat.com/errata/RHSA-2026:6692"
}
]
}
FKIE_CVE-2025-38154
Vulnerability from fkie_nvd - Published: 2025-07-03 09:15 - Updated: 2026-07-30 06:227.8 (High) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 | |
| linux | linux_kernel | 6.10 | |
| debian | debian_linux | 11.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/core/skmsg.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4edb40b05cb6a261775abfd8046804ca139a5546",
"status": "affected",
"version": "4959ffc65a0e94f8acaac20deac49f89e6ded52d",
"versionType": "git"
},
{
"lessThan": "b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9",
"status": "affected",
"version": "5eabdf17fed2ad41b836bb4055ec36d95e512c50",
"versionType": "git"
},
{
"lessThan": "4c6fa65ab2aec7df94809478c8d28ef38676a1b7",
"status": "affected",
"version": "e946428439a0d2079959f5603256ac51b6047017",
"versionType": "git"
},
{
"lessThan": "15c0250dae3b48a398447d2b364603821ed4ed90",
"status": "affected",
"version": "4b4647add7d3c8530493f7247d11e257ee425bf0",
"versionType": "git"
},
{
"lessThan": "7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987",
"status": "affected",
"version": "4b4647add7d3c8530493f7247d11e257ee425bf0",
"versionType": "git"
},
{
"lessThan": "8259eb0e06d8f64c700f5fbdb28a5c18e10de291",
"status": "affected",
"version": "4b4647add7d3c8530493f7247d11e257ee425bf0",
"versionType": "git"
},
{
"status": "affected",
"version": "3627605de498639a3c586c8684d12c89cba11073",
"versionType": "git"
},
{
"lessThan": "5.15.186",
"status": "affected",
"version": "5.15.162",
"versionType": "semver"
},
{
"lessThan": "6.1.142",
"status": "affected",
"version": "6.1.95",
"versionType": "semver"
},
{
"lessThan": "6.6.94",
"status": "affected",
"version": "6.6.35",
"versionType": "semver"
},
{
"lessThan": "6.10",
"status": "affected",
"version": "6.9.6",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/core/skmsg.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.10"
},
{
"lessThan": "6.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.186",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.142",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.94",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.34",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D435B53D-0FAA-4FE8-A253-D3BB51FB33D6",
"versionEndExcluding": "5.15.186",
"versionStartIncluding": "5.15.162",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "09E3982E-A817-487E-AF93-05C0CE745E45",
"versionEndExcluding": "6.1.142",
"versionStartIncluding": "6.1.95",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B5F01BA1-187F-4D06-B1A6-D43397B8DEBD",
"versionEndExcluding": "6.6.94",
"versionStartIncluding": "6.6.35",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AEE76B76-CD40-4103-8E82-768D583AB8A8",
"versionEndExcluding": "6.10",
"versionStartIncluding": "6.9.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "FB4B0709-0132-4A32-8703-77BDD84FDF62",
"versionEndExcluding": "6.12.34",
"versionStartIncluding": "6.10.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0541C761-BD5E-4C1A-8432-83B375D7EB92",
"versionEndExcluding": "6.15.3",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:-:*:*:*:*:*:*",
"matchCriteriaId": "9EA80796-744E-45F5-8632-2AB4F7889FCD",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc2:*:*:*:*:*:*",
"matchCriteriaId": "331C2F14-12C7-45D5-893D-8C52EE38EA10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc3:*:*:*:*:*:*",
"matchCriteriaId": "3173713D-909A-4DD3-9DD4-1E171EB057EE",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc4:*:*:*:*:*:*",
"matchCriteriaId": "79F18AFA-40F7-43F0-BA30-7BDB65F918B9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc5:*:*:*:*:*:*",
"matchCriteriaId": "BD973AA4-A789-49BD-8D57-B2846935D3C7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc6:*:*:*:*:*:*",
"matchCriteriaId": "8F3E9E0C-AC3E-4967-AF80-6483E8AB0078",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.10:rc7:*:*:*:*:*:*",
"matchCriteriaId": "11AF4CB9-F697-4EA4-8903-8F9417EFDA8E",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*",
"matchCriteriaId": "FA6FEEC2-9F11-4643-8827-749718254FED",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u003esk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0027\u0027\u0027\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u003erelease() -\u003e sock_map_close()\n sk_socket-\u003eops = NULL\n free(socket)\n sock-\u003eops-\u003esendmsg\n ^\n panic here\n\u0027\u0027\u0027\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0027\u0027\u0027\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u003c=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026psock-\u003ework); \u003c=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0027\u0027\u0027\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0027t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0027\u0027\u0027\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u003cTASK\u003e\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0027\u0027\u0027"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Evite usar sk_socket despu\u00e9s de liberar al enviar El sk-\u0026gt;sk_socket no est\u00e1 bloqueado o referenciado en el hilo del backlog, y durante la llamada a skb_send_sock(), hay una condici\u00f3n de ejecuci\u00f3n con la liberaci\u00f3n de sk_socket. Todos los tipos de sockets (tcp/udp/unix/vsock) se ver\u00e1n afectados. Condiciones de ejecuciones: \u0027\u0027\u0027 CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops-\u0026gt;release() -\u0026gt; sock_map_close() sk_socket-\u0026gt;ops = NULL free(socket) sock-\u0026gt;ops-\u0026gt;sendmsg ^ p\u00e1nico aqu\u00ed \u0027\u0027\u0027 La referencia de psock se convierte en 0 despu\u00e9s de ejecutar sock_map_close(). \u0027\u0027\u0027 void sock_map_close() { ... if (likely(psock)) { ... // !! aqu\u00ed eliminamos psock y la referencia de psock se convierte en 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; \u0026lt;=== El control salta aqu\u00ed mediante goto ... cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== no se ejecuta sk_psock_put(sk, psock); ... } \u0027\u0027\u0027 Bas\u00e1ndonos en el hecho de que ya esperamos a que finalice la cola de trabajo en sock_map_close() si psock est\u00e1 retenido, simplemente aumentamos el recuento de referencias de psock para evitar condiciones de ejecuci\u00f3n. Con este parche, si el hilo de la lista de tareas pendientes se est\u00e1 ejecutando, sock_map_close() esperar\u00e1 a que se complete el hilo de la lista de tareas pendientes y cancelar\u00e1 todo el trabajo pendiente. Si no hay trabajos pendientes en ejecuci\u00f3n, cualquier trabajo pendiente que no haya comenzado para entonces fallar\u00e1 al ser invocado por sk_psock_get(), ya que el recuento de referencias de psock se ha puesto a cero, y sk_psock_drop() cancelar\u00e1 todos los trabajos mediante cancel_delayed_work_sync(). En resumen, necesitamos sincronizaci\u00f3n para coordinar el hilo de trabajo pendiente y el hilo de cierre. El p\u00e1nico que me entr\u00f3: \u0027\u0027\u0027 Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... \u0027\u0027\u0027 "
}
],
"id": "CVE-2025-38154",
"lastModified": "2026-07-30T06:22:55.597",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-07-03T09:15:30.363",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8259eb0e06d8f64c700f5fbdb28a5c18e10de291"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-VVJ3-J4JG-68HM
Vulnerability from github – Published: 2025-07-03 09:30 – Updated: 2025-12-18 21:31In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.
Race conditions: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''
The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''
Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread and close() thread.
The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''
{
"affected": [],
"aliases": [
"CVE-2025-38154"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-03T09:15:30Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u003esk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0027\u0027\u0027\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u003erelease() -\u003e sock_map_close()\n sk_socket-\u003eops = NULL\n free(socket)\n sock-\u003eops-\u003esendmsg\n ^\n panic here\n\u0027\u0027\u0027\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0027\u0027\u0027\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u003c=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026psock-\u003ework); \u003c=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0027\u0027\u0027\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0027t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0027\u0027\u0027\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u003cTASK\u003e\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0027\u0027\u0027",
"id": "GHSA-vvj3-j4jg-68hm",
"modified": "2025-12-18T21:31:33Z",
"published": "2025-07-03T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c0a16f6ea2b1c82a03bccd5d1bdb4a7bbd4d987"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8259eb0e06d8f64c700f5fbdb28a5c18e10de291"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b19cbf0b9a91f5a0d93fbcd761ff71c48ab40ed9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
oesa-2025-2120
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
gtp: Destroy device along with udp socket's netns dismantle.
gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.
Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]
In this example, gtp0 is created in ns2, and the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1
Let's link the device to the socket's netns instead.
Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.
[0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) _syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) _sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated---(CVE-2025-21678)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix possible crash when setting up bsg fails
If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value. Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)" will not be satisfied, preventing execution from entering bsg_remove_queue(), which could lead to the following crash:
BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace: <TASK> mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr] mpi3mr_remove+0x6f/0x340 [mpi3mr] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19d/0x220 unbind_store+0xa4/0xb0 kernfs_fop_write_iter+0x11f/0x200 vfs_write+0x1fc/0x3e0 ksys_write+0x67/0xe0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)
In the Linux kernel, the following vulnerability has been resolved:
tcp: drop secpath at the same time as we currently drop dst
Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns
The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free'd by skb_attempt_defer_free.
The problem happens when we defer freeing an skb (push it on one CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don't expect at this point.
We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.(CVE-2025-21864)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix type confusion via race condition when using ipc_msg_send_request
req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.(CVE-2025-21947)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: prevent connection release during oplock break notification
ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.(CVE-2025-21955)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix error code in chan_alloc_skb_cb()
The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent.
However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as
pods' addresses are in the fd00::/8 ULA subnet and need to be replaced
with the node's external address. Cilium leverages Envoy to enforce L7
policies, and Envoy uses transparent sockets. Cilium inserts an iptables
prerouting rule that matches on -m socket --transparent and redirects
the packets to localhost, but it fails to match SNATed IPv6 packets due
to that missing conntrack lookup.(CVE-2025-22021)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_tunnel: fix geneve_opt type confusion addition
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] _syssendmsg+0x409/0x450 [ 7.002391] _sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse and dump code.(CVE-2025-22056)
In the Linux kernel, the following vulnerability has been resolved:
net: decrease cached dst counters in dst_release
Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:
Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30
Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.(CVE-2025-22057)
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed:
sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.
This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.(CVE-2025-22063)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: don't unregister hook when table is dormant
When nf_tables_updchain encounters an error, hook registration needs to be rolled back.
This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive).
Just move the assignment into the registration block.(CVE-2025-22064)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.
The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number.
Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 </TASK>(CVE-2025-22086)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Don't expose hw_counters outside of init net namespace
Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one:
[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: error_code(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] <TASK> [42021.953842] [<ffffffff86c58674>] ? show_regs+0x64/0x70 [42021.959030] [<ffffffff86c58468>] ? __die+0x78/0xc0 [42021.963874] [<ffffffff86c9ef75>] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [<ffffffff87674b92>] ? exc_page_fault+0x1a2/0x3c0 [42021.975549] [<ffffffff87801326>] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [<ffffffffc0775680>] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [<ffffffffc077564e>] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [<ffffffff86ac7f8e>] dev_attr_show+0x1e/0x50 [42022.000803] [<ffffffff86a3eeb1>] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [<ffffffff86a11134>] seq_read_iter+0xf4/0x410 [42022.011954] [<ffffffff869f4b2e>] vfs_read+0x16e/0x2f0 [42022.017058] [<ffffffff869f50ee>] ksys_read+0x6e/0xe0 [42022.022073] [<ffffffff8766f1ca>] do_syscall_64+0x6a/0xa0 [42022.027441] [<ffffffff8780013b>] entry_SYSCALL_64_after_hwframe+0x78/0xe2
The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*
The panic occurs because of casting the device pointer into an ib_device pointer using container_of() in hw_stat_device_show() is wrong and leads to a memory corruption.
However the real problem is that hw counters should never been exposed outside of the non-init net namespace.
Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization.
With this fix applied hw_counters are not available in a non-init net namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters
ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: unregister xdp rxq info in the reset path
vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace.
Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0
This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)
In the Linux kernel, the following vulnerability has been resolved:
net: ppp: Add bound checking for skb data on ppp_sync_txmung
Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets.
When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 }
from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,
it is not safe to access data[2].
[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: move the limit validation
It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed.
Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations:
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
This fixes the following syzkaller reported crash:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix workqueue crash in cma_netevent_work_handler
struct rdma_cm_id has member "struct work_struct net_work" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq.
Below crash[1] can occur if more than one call to cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue.
Also drgn analysis [2] indicates the work item was likely overwritten.
Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread.
[1] Trimmed crash stack:
BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 =============================================
[2] drgn crash analysis:
>>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9)
Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
>>> trace[8]["work"] (struct work_struct )0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head )0xffff924d075924c0, .prev = (struct list_head )0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, }
Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *)<absent>
In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work);
and get_work_pwq() is: static struct pool_workqueue get_work_pwq(struct work_struct work) { unsigned long data = atomic_long_read(&work->data);
if (data & WORK_STRUCT_PWQ)
return work_struct_pwq(data);
else
return NULL;
}
WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4)
But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================(CVE-2025-37772)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix nested key length validation in the set() action
It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Purge vif txq in ieee80211_do_stop()
After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state.
Because vif.drv_priv is now cleared in this function, this could lead to driver crash.
For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below.
Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158
To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()
cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37829)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: don't try to reclaim hwpoison folio
Syzkaller reports a bug as follows:
Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20
I can reproduce this issue with the following steps:
1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.
2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.
3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared.
To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list.(CVE-2025-37834)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: avoid infinite loop to schedule delayed worker
We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1].
Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally.
This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry().
[1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)
In the Linux kernel, the following vulnerability has been resolved:
igc: fix PTM cycle trigger logic
Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction.
The issue can be reproduced with the following:
$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m
Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue.
PHC2SYS exits with:
"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails
This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM.
The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle.
When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump.
With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)
In the Linux kernel, the following vulnerability has been resolved:
9p/net: fix improper handling of bogus negative read/write replies
In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed.
Make variables unsigned to avoid this problem.
The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)(CVE-2025-37879)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reset IRTE to host control if new route isn't postable
Restore an IRTE back to host control (remapped or posted MSI mode) if the new GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.
The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.(CVE-2025-37885)
In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: Fix memleak issue when GSO enabled
Always map the skb to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak(CVE-2025-37909)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix out-of-bound memcpy() during ethtool -w
When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption:
BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80
...
This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf.
In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information.
This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.(CVE-2025-37911)
In the Linux kernel, the following vulnerability has been resolved:
ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()
As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI pointer values"), we need to perform a null pointer check on the return value of ice_get_vf_vsi() before using it.(CVE-2025-37912)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY
DSA has 2 kinds of drivers:
- Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
- Those who don't: all others. The above methods should be optional.
For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.
Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered:
WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&
phydev->state != PHY_UP);
because the PHY state machine is running.
It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user.
The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs.
mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible.
This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected:
$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c
Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.
Thus, for the situation where the PM is not managed b ---truncated---(CVE-2025-37945)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Scrub packet on bpf_redirect_peer
When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace.
As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function.
NETNS MARK IFACE TUPLE FUNC
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive
.active_extensions = (__u8)2,
[...]
4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core
.active_extensions = (__u8)2,
[...]
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)
.active_extensions = (__u8)2,
In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption.
This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.(CVE-2025-37959)
In the Linux kernel, the following vulnerability has been resolved:
memblock: Accept allocated memory before use in memblock_double_array()
When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest:
RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b
Mitigate this by calling accept_memory() on the memory range returned before the slab is available.
Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.(CVE-2025-37960)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix uninit-value for saddr in do_output_route4
syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr.
[1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---(CVE-2025-37961)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: leds: fix memory leak
A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code.
The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound.
This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer.
Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.(CVE-2025-37989)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()
The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions.
Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized.
Improve the error message to report more detailed error information.(CVE-2025-37990)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add missing rcu read protection for procfs content
When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF).
As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.(CVE-2025-38003)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking for bcm_op runtime updates
The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero.
Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.(CVE-2025-38004)
In the Linux kernel, the following vulnerability has been resolved:
phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking
The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as:
[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270
The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count.
To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually.
With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles.
The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices
The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices:
# ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP
(Note that the neighbor is not marked with 'offload')
When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one:
# devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP
If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted:
# ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1
Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Disable MACsec offload for uplink representor profile
MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features.
If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set.
Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().
Kernel log:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: <TASK> ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 _syssendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen ---truncated---(CVE-2025-38020)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem
Call Trace:
__dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] _syssendmsg+0xa95/0xc70 net/socket.c:2566 _sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes.
The root cause is: the function ib_device_rename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time.
The solution is to add the lock protection when this name is accessed in the function kobject_uevent().(CVE-2025-38022)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur.
The solution is to let rxe_cleanup do all the work.(CVE-2025-38024)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled
When attempting to enable MQPRIO while HTB offload is already
configured, the driver currently returns -EINVAL and triggers a
WARN_ON, leading to an unnecessary call trace.
Update the code to handle this case more gracefully by returning
-EOPNOTSUPP instead, while also providing a helpful user message.(CVE-2025-38039)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn
The user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can run on multiple platforms having different DMA architectures. On some platforms there can be one FDQ for all flows in the RX channel while for others there is a separate FDQ for each flow in the RX channel.
So far we have been relying on the skip_fdq argument of k3_udma_glue_reset_rx_chn().
Instead of relying on the user to provide this information, infer it based on DMA architecture during k3_udma_glue_request_rx_chn() and save it in an internal flag 'single_fdq'. Use that flag at k3_udma_glue_reset_rx_chn() to deicide if the FDQ needs to be cleared for every flow or just for flow 0.
Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.
> ip link set eth1 down > ip link set eth0 down > ethtool -L eth0 rx 8 > ip link set eth0 up > modprobe -r ti_am65_cpsw_nuss
[ 103.045726] ------------[ cut here ]------------ [ 103.050505] k3_knav_desc_pool size 512000 != avail 64000 [ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool] [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT) [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.154709] sp : ffff8000826ebbc0 [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [ 103.229274] Call trace: [ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P) [ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss] [ 103.244942] devm_action_release+0x14/0x20 [ 103.249040] release_nodes+0x3c/0x68 [ 103.252610] devres_release_all+0x8c/0xdc [ 103.256614] device_unbind_cleanup+0x18/0x60 [ 103.260876] device_release_driver_internal+0xf8/0x178 [ 103.266004] driver_detach+0x50/0x9c [ 103.269571] bus_remove_driver+0x6c/0xbc [ 103.273485] driver_unregister+0x30/0x60 [ 103.277401] platform_driver_unregister+0x14/0x20 [ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss] [ 103.288620] __arm64_sys_delete_module+0x17c/0x25c [ 103.293404] invoke_syscall+0x44/0x100 [ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0 [ 103.301845] do_el0_svc+0x1c/0x28 [ 103.305155] el0_svc+0x28/0x98 ---truncated---(CVE-2025-38042)
In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: set device_caps for 417
The video_device for the MPEG encoder did not set device_caps.
Add this, otherwise the video device can't be registered (you get a WARN_ON instead).
Not seen before since currently 417 support is disabled, but I found this while experimenting with it.(CVE-2025-38044)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: fix skb leaks
A few error paths are missing a kfree_skb.(CVE-2025-38057)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: prevent BUG_ON by blocking retries on failed device resumes
A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object.
Reproduce steps:
- create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.
cat <<EOF >> cmeta.xml <superblock uuid="" block_size="128" nr_cache_blocks="512" \ policy="smq" hint_width="4"> <mappings> <mapping cache_block="0" origin_block="0" dirty="false"/> </mappings> </superblock> EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta
- wipe the second array block of the mapping array to simulate data degradations.
mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock
- try bringing up the cache device. The resume is expected to fail due to the broken array block.
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache
- try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.
dmsetup resume cache
Kernel logs:
(snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570
Fix by disallowing resume operations for devices that failed the initial attempt.(CVE-2025-38066)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed.
If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected.
Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.(CVE-2025-38085)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix use-after-free in taprio_dev_notifier
Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free.
Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.
The reference chain is: xfrm_state -> enacp_sk -> netns
Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.
This patch results in a small (~2% in my tests) performance regression.
A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.(CVE-2025-38097)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: Fix use-after-free in page_pool_recycle_in_ring
syzbot reported a uaf in page_pool_recycle_in_ring:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943
CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]
root cause is:
page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free
spin_unlock(&r->producer_lock); //pool->ring uaf read
recycle_stat_inc(pool, ring);
page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled.
recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.(CVE-2025-38129)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.
Race conditions: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''
The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''
Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread and close() thread.
The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix panic when calling skb_linearize
The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000
Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] <TASK> [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfxlockrelease.isra.0+0x10/0x10 [ 657.473826] pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 '''
The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed.
The "--rx-strp 100000" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.
To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.
''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress__ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply___↑ skb_linearize '''
Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior.(CVE-2025-38165)
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix ktls panic with sockmap
[ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] <TASK> [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ......
After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data().
If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); '''
The changes in this commit are based on the following considerations:
-
When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic.
-
We can not calculate the correct number of bytes to revert msg_iter.
Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement.
However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed.
So it doesn't seem as simple as just reverting through an offset of msg_iter.
- For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached.
Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; '''
So it's ok to just return 'copied' without error when a "cork" situation occurs.(CVE-2025-38166)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush
In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated.
However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way.
Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.(CVE-2025-38351)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks
After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.(CVE-2025-38412)
In the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net->xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net->collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)
In the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)
In the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Prevent VMA split of buffer mappings
The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct.
Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks.
As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented.
Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL.
That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.(CVE-2025-38563)
In the Linux kernel, the following vulnerability has been resolved:
benet: fix BUG when creating VFs
benet crashes as soon as SRIOV VFs are created:
kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: <TASK> __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0
be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh. Fix it by freeing only after the lock has been released.(CVE-2025-38569)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix double destruction of rsv_qp
rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init().
list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18(CVE-2025-38582)
In the Linux kernel, the following vulnerability has been resolved:
vmci: Prevent the dispatching of uninitialized payloads
The reproducer executes the host's unlocked_ioctl call in two different tasks. When init_context fails, the struct vmci_event_ctx is not fully initialized when executing vmci_datagram_dispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space.
Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization.(CVE-2025-38611)
In the Linux kernel, the following vulnerability has been resolved:
pinmux: fix race causing mux_owner NULL with active mux_usecount
commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer.
The issue occurs due to the following interleaving:
cpu0 (process A) cpu1 (process B)
pin_request() { pin_free() {
mutex_lock()
desc->mux_usecount--; //becomes 0
..
mutex_unlock()
mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux)
mutex_lock(desc->mux)
desc->mux_owner = NULL;
mutex_unlock(desc->mux)
This sequence leads to a state where the pin appears to be in use
(mux_usecount == 1) but has no owner (mux_owner == NULL), which can
cause NULL pointer on next pin_request on the same pin.
Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned.(CVE-2025-38632)
In the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro's suggestion, it was fixed in the same manner.(CVE-2025-38653)
In the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-source-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"perf-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"python3-perf-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-108.0.0.100.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-source-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"perf-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"python3-perf-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.100.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-108.0.0.100.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: Destroy device along with udp socket\u0026apos;s netns dismantle.\n\ngtp_newlink() links the device to a list in dev_net(dev) instead of\nsrc_net, where a udp tunnel socket is created.\n\nEven when src_net is removed, the device stays alive on dev_net(dev).\nThen, removing src_net triggers the splat below. [0]\n\nIn this example, gtp0 is created in ns2, and the udp socket is created\nin ns1.\n\n ip netns add ns1\n ip netns add ns2\n ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn\n ip netns del ns1\n\nLet\u0026apos;s link the device to the socket\u0026apos;s netns instead.\n\nNow, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove\nall gtp devices in the netns.\n\n[0]:\nref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at\n sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)\n inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)\n __sock_create (net/socket.c:1558)\n udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)\n gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)\n gtp_create_sockets (drivers/net/gtp.c:1447)\n gtp_newlink (drivers/net/gtp.c:1507)\n rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)\n netlink_rcv_skb (net/netlink/af_netlink.c:2542)\n netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)\n netlink_sendmsg (net/netlink/af_netlink.c:1891)\n ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)\n ___sys_sendmsg (net/socket.c:2639)\n __sys_sendmsg (net/socket.c:2669)\n do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n\nWARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\nModules linked in:\nCPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: netns cleanup_net\nRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)\nCode: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 \u0026lt;0f\u0026gt; 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89\nRSP: 0018:ff11000009a07b60 EFLAGS: 00010286\nRAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c\nRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae\nR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0\nR13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn (kernel/panic.c:748)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:285)\n ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)\n ? kfree (mm/slub.c:4613 mm/slub.c:4761)\n net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)\n cleanup_net (net/core/net_namespace.c:664 (discriminator 3))\n process_one_work (kernel/workqueue.c:3229)\n worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391\n---truncated---(CVE-2025-21678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix possible crash when setting up bsg fails\n\nIf bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value.\nConsequently, in mpi3mr_bsg_exit(), the condition \u0026quot;if(!mrioc-\u0026gt;bsg_queue)\u0026quot;\nwill not be satisfied, preventing execution from entering\nbsg_remove_queue(), which could lead to the following crash:\n\nBUG: kernel NULL pointer dereference, address: 000000000000041c\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]\n mpi3mr_remove+0x6f/0x340 [mpi3mr]\n pci_device_remove+0x3f/0xb0\n device_release_driver_internal+0x19d/0x220\n unbind_store+0xa4/0xb0\n kernfs_fop_write_iter+0x11f/0x200\n vfs_write+0x1fc/0x3e0\n ksys_write+0x67/0xe0\n do_syscall_64+0x38/0x80\n entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: drop secpath at the same time as we currently drop dst\n\nXiumei reported hitting the WARN in xfrm6_tunnel_net_exit while\nrunning tests that boil down to:\n - create a pair of netns\n - run a basic TCP test over ipcomp6\n - delete the pair of netns\n\nThe xfrm_state found on spi_byaddr was not deleted at the time we\ndelete the netns, because we still have a reference on it. This\nlingering reference comes from a secpath (which holds a ref on the\nxfrm_state), which is still attached to an skb. This skb is not\nleaked, it ends up on sk_receive_queue and then gets defer-free\u0026apos;d by\nskb_attempt_defer_free.\n\nThe problem happens when we defer freeing an skb (push it on one CPU\u0026apos;s\ndefer_list), and don\u0026apos;t flush that list before the netns is deleted. In\nthat case, we still have a reference on the xfrm_state that we don\u0026apos;t\nexpect at this point.\n\nWe already drop the skb\u0026apos;s dst in the TCP receive path when it\u0026apos;s no\nlonger needed, so let\u0026apos;s also drop the secpath. At this point,\ntcp_filter has already called into the LSM hooks that may require the\nsecpath, so it should not be needed anymore. However, in some of those\nplaces, the MPTCP extension has just been attached to the skb, so we\ncannot simply drop all extensions.(CVE-2025-21864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix type confusion via race condition when using ipc_msg_send_request\n\nreq-\u0026gt;handle is allocated using ksmbd_acquire_id(\u0026amp;ipc_ida), based on\nida_alloc. req-\u0026gt;handle from ksmbd_ipc_login_request and\nFSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion\nbetween messages, resulting in access to unexpected parts of memory after\nan incorrect delivery. ksmbd check type of ipc response but missing add\ncontinue to check next ipc reponse.(CVE-2025-21947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent connection release during oplock break notification\n\nksmbd_work could be freed when after connection release.\nIncrement r_count of ksmbd_conn to indicate that requests\nare not finished yet and to not release the connection.(CVE-2025-21955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix error code in chan_alloc_skb_cb()\n\nThe chan_alloc_skb_cb() function is supposed to return error pointers on\nerror. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: socket: Lookup orig tuple for IPv6 SNAT\n\nnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to\nrestore the original 5-tuple in case of SNAT, to be able to find the\nright socket (if any). Then socket_match() can correctly check whether\nthe socket was transparent.\n\nHowever, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this\nconntrack lookup, making xt_socket fail to match on the socket when the\npacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.\n\nIPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as\npods\u0026apos; addresses are in the fd00::/8 ULA subnet and need to be replaced\nwith the node\u0026apos;s external address. Cilium leverages Envoy to enforce L7\npolicies, and Envoy uses transparent sockets. Cilium inserts an iptables\nprerouting rule that matches on `-m socket --transparent` and redirects\nthe packets to localhost, but it fails to match SNATed IPv6 packets due\nto that missing conntrack lookup.(CVE-2025-22021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_tunnel: fix geneve_opt type confusion addition\n\nWhen handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the\nparsing logic should place every geneve_opt structure one by one\ncompactly. Hence, when deciding the next geneve_opt position, the\npointer addition should be in units of char *.\n\nHowever, the current implementation erroneously does type conversion\nbefore the addition, which will lead to heap out-of-bounds write.\n\n[ 6.989857] ==================================================================\n[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70\n[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178\n[ 6.991162]\n[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1\n[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[ 6.992281] Call Trace:\n[ 6.992423] \u0026lt;TASK\u0026gt;\n[ 6.992586] dump_stack_lvl+0x44/0x5c\n[ 6.992801] print_report+0x184/0x4be\n[ 6.993790] kasan_report+0xc5/0x100\n[ 6.994252] kasan_check_range+0xf3/0x1a0\n[ 6.994486] memcpy+0x38/0x60\n[ 6.994692] nft_tunnel_obj_init+0x977/0xa70\n[ 6.995677] nft_obj_init+0x10c/0x1b0\n[ 6.995891] nf_tables_newobj+0x585/0x950\n[ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020\n[ 6.998997] nfnetlink_rcv+0x1df/0x220\n[ 6.999537] netlink_unicast+0x395/0x530\n[ 7.000771] netlink_sendmsg+0x3d0/0x6d0\n[ 7.001462] __sock_sendmsg+0x99/0xa0\n[ 7.001707] ____sys_sendmsg+0x409/0x450\n[ 7.002391] ___sys_sendmsg+0xfd/0x170\n[ 7.003145] __sys_sendmsg+0xea/0x170\n[ 7.004359] do_syscall_64+0x5e/0x90\n[ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 7.006127] RIP: 0033:0x7ec756d4e407\n[ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407\n[ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003\n[ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000\n[ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\n[ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8\n\nFix this bug with correct pointer addition and conversion in parse\nand dump code.(CVE-2025-22056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: decrease cached dst counters in dst_release\n\nUpstream fix ac888d58869b (\u0026quot;net: do not delay dst_entries_add() in\ndst_release()\u0026quot;) moved decrementing the dst count from dst_destroy to\ndst_release to avoid accessing already freed data in case of netns\ndismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels\nare used, this fix is incomplete as the same issue will be seen for\ncached dsts:\n\n Unable to handle kernel paging request at virtual address ffff5aabf6b5c000\n Call trace:\n percpu_counter_add_batch+0x3c/0x160 (P)\n dst_release+0xec/0x108\n dst_cache_destroy+0x68/0xd8\n dst_destroy+0x13c/0x168\n dst_destroy_rcu+0x1c/0xb0\n rcu_do_batch+0x18c/0x7d0\n rcu_core+0x174/0x378\n rcu_core_si+0x18/0x30\n\nFix this by invalidating the cache, and thus decrementing cached dst\ncounters, in dst_release too.(CVE-2025-22057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets\n\nWhen calling netlbl_conn_setattr(), addr-\u0026gt;sa_family is used\nto determine the function behavior. If sk is an IPv4 socket,\nbut the connect function is called with an IPv6 address,\nthe function calipso_sock_setattr() is triggered.\nInside this function, the following code is executed:\n\nsk_fullsock(__sk) ? inet_sk(__sk)-\u0026gt;pinet6 : NULL;\n\nSince sk is an IPv4 socket, pinet6 is NULL, leading to a\nnull pointer dereference.\n\nThis patch fixes the issue by checking if inet6_sk(sk)\nreturns a NULL pointer before accessing pinet6.(CVE-2025-22063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don\u0026apos;t unregister hook when table is dormant\n\nWhen nf_tables_updchain encounters an error, hook registration needs to\nbe rolled back.\n\nThis should only be done if the hook has been registered, which won\u0026apos;t\nhappen when the table is flagged as dormant (inactive).\n\nJust move the assignment into the registration block.(CVE-2025-22064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow\n\nWhen cur_qp isn\u0026apos;t NULL, in order to avoid fetching the QP from\nthe radix tree again we check if the next cqe QP is identical to\nthe one we already have.\n\nThe bug however is that we are checking if the QP is identical by\nchecking the QP number inside the CQE against the QP number inside the\nmlx5_ib_qp, but that\u0026apos;s wrong since the QP number from the CQE is from\nFW so it should be matched against mlx5_core_qp which is our FW QP\nnumber.\n\nOtherwise we could use the wrong QP when handling a CQE which could\ncause the kernel trace below.\n\nThis issue is mainly noticeable over QPs 0 \u0026amp; 1, since for now they are\nthe only QPs in our driver whereas the QP number inside mlx5_ib_qp\ndoesn\u0026apos;t match the QP number inside mlx5_core_qp.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\n RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 \u0026lt;0f\u0026gt; b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21\n RSP: 0018:ffff88810511bd60 EFLAGS: 00010046\n RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a\n RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10\n R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000\n R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0\n FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n __ib_process_cq+0x5a/0x150 [ib_core]\n ib_cq_poll_work+0x31/0x90 [ib_core]\n process_one_work+0x169/0x320\n worker_thread+0x288/0x3a0\n ? work_busy+0xb0/0xb0\n kthread+0xd7/0x1f0\n ? kthreads_online_cpu+0x130/0x130\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork+0x2d/0x50\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;(CVE-2025-22086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Don\u0026apos;t expose hw_counters outside of init net namespace\n\nCommit 467f432a521a (\u0026quot;RDMA/core: Split port and device counter sysfs\nattributes\u0026quot;) accidentally almost exposed hw counters to non-init net\nnamespaces. It didn\u0026apos;t expose them fully, as an attempt to read any of\nthose counters leads to a crash like this one:\n\n[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028\n[42021.814463] #PF: supervisor read access in kernel mode\n[42021.819549] #PF: error_code(0x0000) - not-present page\n[42021.824636] PGD 0 P4D 0\n[42021.827145] Oops: 0000 [#1] SMP PTI\n[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX\n[42021.841697] Hardware name: XXX\n[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff \u0026lt;48\u0026gt; 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48\n[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287\n[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000\n[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0\n[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000\n[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530\n[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000\n[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000\n[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0\n[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[42021.949324] Call Trace:\n[42021.951756] \u0026lt;TASK\u0026gt;\n[42021.953842] [\u0026lt;ffffffff86c58674\u0026gt;] ? show_regs+0x64/0x70\n[42021.959030] [\u0026lt;ffffffff86c58468\u0026gt;] ? __die+0x78/0xc0\n[42021.963874] [\u0026lt;ffffffff86c9ef75\u0026gt;] ? page_fault_oops+0x2b5/0x3b0\n[42021.969749] [\u0026lt;ffffffff87674b92\u0026gt;] ? exc_page_fault+0x1a2/0x3c0\n[42021.975549] [\u0026lt;ffffffff87801326\u0026gt;] ? asm_exc_page_fault+0x26/0x30\n[42021.981517] [\u0026lt;ffffffffc0775680\u0026gt;] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]\n[42021.988482] [\u0026lt;ffffffffc077564e\u0026gt;] ? hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.995438] [\u0026lt;ffffffff86ac7f8e\u0026gt;] dev_attr_show+0x1e/0x50\n[42022.000803] [\u0026lt;ffffffff86a3eeb1\u0026gt;] sysfs_kf_seq_show+0x81/0xe0\n[42022.006508] [\u0026lt;ffffffff86a11134\u0026gt;] seq_read_iter+0xf4/0x410\n[42022.011954] [\u0026lt;ffffffff869f4b2e\u0026gt;] vfs_read+0x16e/0x2f0\n[42022.017058] [\u0026lt;ffffffff869f50ee\u0026gt;] ksys_read+0x6e/0xe0\n[42022.022073] [\u0026lt;ffffffff8766f1ca\u0026gt;] do_syscall_64+0x6a/0xa0\n[42022.027441] [\u0026lt;ffffffff8780013b\u0026gt;] entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe problem can be reproduced using the following steps:\n ip netns add foo\n ip netns exec foo bash\n cat /sys/class/infiniband/mlx4_0/hw_counters/*\n\nThe panic occurs because of casting the device pointer into an\nib_device pointer using container_of() in hw_stat_device_show() is\nwrong and leads to a memory corruption.\n\nHowever the real problem is that hw counters should never been exposed\noutside of the non-init net namespace.\n\nFix this by saving the index of the corresponding attribute group\n(it might be 1 or 2 depending on the presence of driver-specific\nattributes) and zeroing the pointer to hw_counters group for compat\ndevices during the initialization.\n\nWith this fix applied hw_counters are not available in a non-init\nnet namespace:\n find /sys/class/infiniband/mlx4_0/ -name hw_counters\n /sys/class/infiniband/mlx4_0/ports/1/hw_counters\n /sys/class/infiniband/mlx4_0/ports/2/hw_counters\n /sys/class/infiniband/mlx4_0/hw_counters\n\n ip netns add foo\n ip netns exec foo bash\n find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: unregister xdp rxq info in the reset path\n\nvmxnet3 does not unregister xdp rxq info in the\nvmxnet3_reset_work() code path as vmxnet3_rq_destroy()\nis not invoked in this code path. So, we get below message with a\nbacktrace.\n\nMissing unregister, handled but fix driver\nWARNING: CPU:48 PID: 500 at net/core/xdp.c:182\n__xdp_rxq_info_reg+0x93/0xf0\n\nThis patch fixes the problem by moving the unregister\ncode of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ppp: Add bound checking for skb data on ppp_sync_txmung\n\nEnsure we have enough data in linear buffer from skb before accessing\ninitial bytes. This prevents potential out-of-bounds accesses\nwhen processing short packets.\n\nWhen ppp_sync_txmung receives an incoming package with an empty\npayload:\n(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)\n$18 = {\n\ttype = 0x1,\n\tver = 0x1,\n\tcode = 0x0,\n\tsid = 0x2,\n length = 0x0,\n\ttag = 0xffff8880371cdb96\n}\n\nfrom the skb struct (trimmed)\n tail = 0x16,\n end = 0x140,\n head = 0xffff88803346f400 \u0026quot;4\u0026quot;,\n data = 0xffff88803346f416 \u0026quot;:\\377\u0026quot;,\n truesize = 0x380,\n len = 0x0,\n data_len = 0x0,\n mac_len = 0xe,\n hdr_len = 0x0,\n\nit is not safe to access data[2].\n\n[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: move the limit validation\n\nIt is not sufficient to directly validate the limit on the data that\nthe user passes as it can be updated based on how the other parameters\nare changed.\n\nMove the check at the end of the configuration update process to also\ncatch scenarios where the limit is indirectly updated, for example\nwith the following configurations:\n\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1\n\nThis fixes the following syzkaller reported crash:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6\nindex 65535 is out of range for type \u0026apos;struct sfq_head[128]\u0026apos;\nCPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429\n sfq_link net/sched/sch_sfq.c:203 [inline]\n sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231\n sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493\n sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311\n netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]\n dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix workqueue crash in cma_netevent_work_handler\n\nstruct rdma_cm_id has member \u0026quot;struct work_struct net_work\u0026quot;\nthat is reused for enqueuing cma_netevent_work_handler()s\nonto cma_wq.\n\nBelow crash[1] can occur if more than one call to\ncma_netevent_callback() occurs in quick succession,\nwhich further enqueues cma_netevent_work_handler()s for the\nsame rdma_cm_id, overwriting any previously queued work-item(s)\nthat was just scheduled to run i.e. there is no guarantee\nthe queued work item may run between two successive calls\nto cma_netevent_callback() and the 2nd INIT_WORK would overwrite\nthe 1st work item (for the same rdma_cm_id), despite grabbing\nid_table_lock during enqueue.\n\nAlso drgn analysis [2] indicates the work item was likely overwritten.\n\nFix this by moving the INIT_WORK() to __rdma_create_id(),\nso that it doesn\u0026apos;t race with any existing queue_work() or\nits worker thread.\n\n[1] Trimmed crash stack:\n=============================================\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nkworker/u256:6 ... 6.12.0-0...\nWorkqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)\nRIP: 0010:process_one_work+0xba/0x31a\nCall Trace:\n worker_thread+0x266/0x3a0\n kthread+0xcf/0x100\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n=============================================\n\n[2] drgn crash analysis:\n\n\u0026gt;\u0026gt;\u0026gt; trace = prog.crashed_thread().stack_trace()\n\u0026gt;\u0026gt;\u0026gt; trace\n(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)\n(1) __crash_kexec (kernel/crash_core.c:122:4)\n(2) panic (kernel/panic.c:399:3)\n(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)\n...\n(8) process_one_work (kernel/workqueue.c:3168:2)\n(9) process_scheduled_works (kernel/workqueue.c:3310:3)\n(10) worker_thread (kernel/workqueue.c:3391:4)\n(11) kthread (kernel/kthread.c:389:9)\n\nLine workqueue.c:3168 for this kernel version is in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;work\u0026quot;]\n*(struct work_struct *)0xffff92577d0a21d8 = {\n\t.data = (atomic_long_t){\n\t\t.counter = (s64)536870912, \u0026lt;=== Note\n\t},\n\t.entry = (struct list_head){\n\t\t.next = (struct list_head *)0xffff924d075924c0,\n\t\t.prev = (struct list_head *)0xffff924d075924c0,\n\t},\n\t.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,\n}\n\nSuspicion is that pwq is NULL:\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;pwq\u0026quot;]\n(struct pool_workqueue *)\u0026lt;absent\u0026gt;\n\nIn process_one_work(), pwq is assigned from:\nstruct pool_workqueue *pwq = get_work_pwq(work);\n\nand get_work_pwq() is:\nstatic struct pool_workqueue *get_work_pwq(struct work_struct *work)\n{\n \tunsigned long data = atomic_long_read(\u0026amp;work-\u0026gt;data);\n\n \tif (data \u0026amp; WORK_STRUCT_PWQ)\n \t\treturn work_struct_pwq(data);\n \telse\n \t\treturn NULL;\n}\n\nWORK_STRUCT_PWQ is 0x4:\n\u0026gt;\u0026gt;\u0026gt; print(repr(prog[\u0026apos;WORK_STRUCT_PWQ\u0026apos;]))\nObject(prog, \u0026apos;enum work_flags\u0026apos;, value=4)\n\nBut work-\u0026gt;data is 536870912 which is 0x20000000.\nSo, get_work_pwq() returns NULL and we crash in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n=============================================(CVE-2025-37772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt\u0026apos;s not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Purge vif txq in ieee80211_do_stop()\n\nAfter ieee80211_do_stop() SKB from vif\u0026apos;s txq could still be processed.\nIndeed another concurrent vif schedule_and_wake_txq call could cause\nthose packets to be dequeued (see ieee80211_handle_wake_tx_queue())\nwithout checking the sdata current state.\n\nBecause vif.drv_priv is now cleared in this function, this could lead to\ndriver crash.\n\nFor example in ath12k, ahvif is store in vif.drv_priv. Thus if\nath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif-\u0026gt;ah can be\nNULL, leading the ath12k_warn(ahvif-\u0026gt;ah,...) call in this function to\ntrigger the NULL deref below.\n\n Unable to handle kernel paging request at virtual address dfffffc000000001\n KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n batman_adv: bat0: Interface deactivated: brbh1337\n Mem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n [dfffffc000000001] address between user and kernel address ranges\n Internal error: Oops: 0000000096000004 [#1] SMP\n CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114\n Hardware name: HW (DT)\n pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]\n lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]\n sp : ffffffc086ace450\n x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4\n x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e\n x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0\n x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958\n x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8\n x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03\n x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40\n x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0\n x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001\n x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008\n Call trace:\n ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)\n ieee80211_handle_wake_tx_queue+0x16c/0x260\n ieee80211_queue_skb+0xeec/0x1d20\n ieee80211_tx+0x200/0x2c8\n ieee80211_xmit+0x22c/0x338\n __ieee80211_subif_start_xmit+0x7e8/0xc60\n ieee80211_subif_start_xmit+0xc4/0xee0\n __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0\n ieee80211_subif_start_xmit_8023+0x124/0x488\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n br_dev_queue_push_xmit+0x120/0x4a8\n __br_forward+0xe4/0x2b0\n deliver_clone+0x5c/0xd0\n br_flood+0x398/0x580\n br_dev_xmit+0x454/0x9f8\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n ip6_finish_output2+0xc28/0x1b60\n __ip6_finish_output+0x38c/0x638\n ip6_output+0x1b4/0x338\n ip6_local_out+0x7c/0xa8\n ip6_send_skb+0x7c/0x1b0\n ip6_push_pending_frames+0x94/0xd0\n rawv6_sendmsg+0x1a98/0x2898\n inet_sendmsg+0x94/0xe0\n __sys_sendto+0x1e4/0x308\n __arm64_sys_sendto+0xc4/0x140\n do_el0_svc+0x110/0x280\n el0_svc+0x20/0x60\n el0t_64_sync_handler+0x104/0x138\n el0t_64_sync+0x154/0x158\n\nTo avoid that, empty vif\u0026apos;s txq at ieee80211_do_stop() so no packet could\nbe dequeued after ieee80211_do_stop() (new packets cannot be queued\nbecause SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy-\u0026gt;cpus mask. scpi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.(CVE-2025-37829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don\u0026apos;t try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n page isn\u0026apos;t locked, inject memory failure for the page. \n me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n but fails. Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn\u0026apos;t in lru list.(CVE-2025-37834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: avoid infinite loop to schedule delayed worker\n\nWe noticed the kworker in page_pool_release_retry() was waken\nup repeatedly and infinitely in production because of the\nbuggy driver causing the inflight less than 0 and warning\nus in page_pool_inflight()[1].\n\nSince the inflight value goes negative, it means we should\nnot expect the whole page_pool to get back to work normally.\n\nThis patch mitigates the adverse effect by not rescheduling\nthe kworker when detecting the inflight negative in\npage_pool_release_retry().\n\n[1]\n[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------\n[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages\n...\n[Mon Feb 10 20:36:11 2025] Call Trace:\n[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70\n[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370\n[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0\n[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140\n[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370\n[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40\n[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40\n[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---\nNote: before this patch, the above calltrace would flood the\ndmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigc: fix PTM cycle trigger logic\n\nWriting to clear the PTM status \u0026apos;valid\u0026apos; bit while the PTM cycle is\ntriggered results in unreliable PTM operation. To fix this, clear the\nPTM \u0026apos;trigger\u0026apos; and status after each PTM transaction.\n\nThe issue can be reproduced with the following:\n\n$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m\n\nNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way to\nquickly reproduce the issue.\n\nPHC2SYS exits with:\n\n\u0026quot;ioctl PTP_OFFSET_PRECISE: Connection timed out\u0026quot; when the PTM transaction\n fails\n\nThis patch also fixes a hang in igc_probe() when loading the igc\ndriver in the kdump kernel on systems supporting PTM.\n\nThe igc driver running in the base kernel enables PTM trigger in\nigc_probe(). Therefore the driver is always in PTM trigger mode,\nexcept in brief periods when manually triggering a PTM cycle.\n\nWhen a crash occurs, the NIC is reset while PTM trigger is enabled.\nDue to a hardware problem, the NIC is subsequently in a bad busmaster\nstate and doesn\u0026apos;t handle register reads/writes. When running\nigc_probe() in the kdump kernel, the first register access to a NIC\nregister hangs driver probing and ultimately breaks kdump.\n\nWith this patch, igc has PTM trigger disabled most of the time,\nand the trigger is only enabled for very brief (10 - 100 us) periods\nwhen manually triggering a PTM cycle. Chances that a crash occurs\nduring a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/net: fix improper handling of bogus negative read/write replies\n\nIn p9_client_write() and p9_client_read_once(), if the server\nincorrectly replies with success but a negative write/read count then we\nwould consider written (negative) \u0026lt;= rsize (positive) because both\nvariables were signed.\n\nMake variables unsigned to avoid this problem.\n\nThe reproducer linked below now fails with the following error instead\nof a null pointer deref:\n9pnet: bogus RWRITE count (4294967295 \u0026gt; 3)(CVE-2025-37879)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reset IRTE to host control if *new* route isn\u0026apos;t postable\n\nRestore an IRTE back to host control (remapped or posted MSI mode) if the\n*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of\nthe GSI routing type. Updating the IRTE if and only if the new GSI is an\nMSI results in KVM leaving an IRTE posting to a vCPU.\n\nThe dangling IRTE can result in interrupts being incorrectly delivered to\nthe guest, and in the worst case scenario can result in use-after-free,\ne.g. if the VM is torn down, but the underlying host IRQ isn\u0026apos;t freed.(CVE-2025-37885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: Fix memleak issue when GSO enabled\n\nAlways map the `skb` to the LS descriptor. Previously skb was\nmapped to EXT descriptor when the number of fragments is zero with\nGSO enabled. Mapping the skb to EXT descriptor prevents it from\nbeing freed, leading to a memory leak(CVE-2025-37909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix out-of-bound memcpy() during ethtool -w\n\nWhen retrieving the FW coredump using ethtool, it can sometimes cause\nmemory corruption:\n\nBUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nCorrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):\n__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nethtool_get_dump_data+0xdc/0x1a0\n__dev_ethtool+0xa1e/0x1af0\ndev_ethtool+0xa8/0x170\ndev_ioctl+0x1b5/0x580\nsock_do_ioctl+0xab/0xf0\nsock_ioctl+0x1ce/0x2e0\n__x64_sys_ioctl+0x87/0xc0\ndo_syscall_64+0x5c/0xf0\nentry_SYSCALL_64_after_hwframe+0x78/0x80\n\n...\n\nThis happens when copying the coredump segment list in\nbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.\nThe info-\u0026gt;dest_buf buffer is allocated based on the number of coredump\nsegments returned by the FW. The segment list is then DMA\u0026apos;ed by\nthe FW and the length of the DMA is returned by FW. The driver then\ncopies this DMA\u0026apos;ed segment list to info-\u0026gt;dest_buf.\n\nIn some cases, this DMA length may exceed the info-\u0026gt;dest_buf length\nand cause the above BUG condition. Fix it by capping the copy\nlength to not exceed the length of info-\u0026gt;dest_buf. The extra\nDMA data contains no useful information.\n\nThis code path is shared for the HWRM_DBG_COREDUMP_LIST and the\nHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different\nfor these 2 FW commands. To simplify the logic, we need to move\nthe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE\nup, so that the new check to cap the copy length will work for both\ncommands.(CVE-2025-37911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()\n\nAs mentioned in the commit baeb705fd6a7 (\u0026quot;ice: always check VF VSI\npointer values\u0026quot;), we need to perform a null pointer check on the return\nvalue of ice_get_vf_vsi() before using it.(CVE-2025-37912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY\n\nDSA has 2 kinds of drivers:\n\n1. Those who call dsa_switch_suspend() and dsa_switch_resume() from\n their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz\n2. Those who don\u0026apos;t: all others. The above methods should be optional.\n\nFor type 1, dsa_switch_suspend() calls dsa_user_suspend() -\u0026gt; phylink_stop(),\nand dsa_switch_resume() calls dsa_user_resume() -\u0026gt; phylink_start().\nThese seem good candidates for setting mac_managed_pm = true because\nthat is essentially its definition [1], but that does not seem to be the\nbiggest problem for now, and is not what this change focuses on.\n\nTalking strictly about the 2nd category of DSA drivers here (which\ndo not have MAC managed PM, meaning that for their attached PHYs,\nmdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),\nI have noticed that the following warning from mdio_bus_phy_resume() is\ntriggered:\n\n\tWARN_ON(phydev-\u0026gt;state != PHY_HALTED \u0026amp;\u0026amp; phydev-\u0026gt;state != PHY_READY \u0026amp;\u0026amp;\n\t\tphydev-\u0026gt;state != PHY_UP);\n\nbecause the PHY state machine is running.\n\nIt\u0026apos;s running as a result of a previous dsa_user_open() -\u0026gt; ... -\u0026gt;\nphylink_start() -\u0026gt; phy_start() having been initiated by the user.\n\nThe previous mdio_bus_phy_suspend() was supposed to have called\nphy_stop_machine(), but it didn\u0026apos;t. So this is why the PHY is in state\nPHY_NOLINK by the time mdio_bus_phy_resume() runs.\n\nmdio_bus_phy_suspend() did not call phy_stop_machine() because for\nphylink, the phydev-\u0026gt;adjust_link function pointer is NULL. This seems a\ntechnicality introduced by commit fddd91016d16 (\u0026quot;phylib: fix PAL state\nmachine restart on resume\u0026quot;). That commit was written before phylink\nexisted, and was intended to avoid crashing with consumer drivers which\ndon\u0026apos;t use the PHY state machine - phylink always does, when using a PHY.\nBut phylink itself has historically not been developed with\nsuspend/resume in mind, and apparently not tested too much in that\nscenario, allowing this bug to exist unnoticed for so long. Plus, prior\nto the WARN_ON(), it would have likely been invisible.\n\nThis issue is not in fact restricted to type 2 DSA drivers (according to\nthe above ad-hoc classification), but can be extrapolated to any MAC\ndriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where\nthe issue was reported. Assuming mac_managed_pm is set correctly, a\nquick search indicates the following other drivers might be affected:\n\n$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm\ndrivers/net/ethernet/atheros/ag71xx.c\ndrivers/net/ethernet/microchip/sparx5/sparx5_main.c\ndrivers/net/ethernet/microchip/lan966x/lan966x_main.c\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c\ndrivers/net/ethernet/freescale/fs_enet/fs_enet-main.c\ndrivers/net/ethernet/freescale/dpaa/dpaa_eth.c\ndrivers/net/ethernet/freescale/ucc_geth.c\ndrivers/net/ethernet/freescale/enetc/enetc_pf_common.c\ndrivers/net/ethernet/marvell/mvpp2/mvpp2_main.c\ndrivers/net/ethernet/marvell/mvneta.c\ndrivers/net/ethernet/marvell/prestera/prestera_main.c\ndrivers/net/ethernet/mediatek/mtk_eth_soc.c\ndrivers/net/ethernet/altera/altera_tse_main.c\ndrivers/net/ethernet/wangxun/txgbe/txgbe_phy.c\ndrivers/net/ethernet/meta/fbnic/fbnic_phylink.c\ndrivers/net/ethernet/tehuti/tn40_phy.c\ndrivers/net/ethernet/mscc/ocelot_net.c\n\nMake the existing conditions dependent on the PHY device having a\nphydev-\u0026gt;phy_link_change() implementation equal to the default\nphy_link_change() provided by phylib. Otherwise, we implicitly know that\nthe phydev has the phylink-provided phylink_phy_change() callback, and\nwhen phylink is used, the PHY state machine always needs to be stopped/\nstarted on the suspend/resume path. The code is structured as such that\nif phydev-\u0026gt;phy_link_change() is absent, it is a matter of time until the\nkernel will crash - no need to further complicate the test.\n\nThus, for the situation where the PM is not managed b\n---truncated---(CVE-2025-37945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn\u0026apos;t scrubbed. That can lead skb\ninformation from one namespace to be \u0026quot;misused\u0026quot; in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host\u0026apos;s XFRM layer to the container\u0026apos;s XFRM\nlayer where it\u0026apos;s dropped and (2) the number of active skb extensions at\neach function.\n\n NETNS MARK IFACE TUPLE FUNC\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm4_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 gro_cells_receive\n .active_extensions = (__u8)2,\n [...]\n 4026533547 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 skb_do_redirect\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv_core\n .active_extensions = (__u8)2,\n [...]\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 udp_queue_rcv_one_skb\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_policy_check\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 security_xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container\u0026apos;s network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container\u0026apos;s netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can\u0026apos;t be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb-\u0026gt;mark and skb-\u0026gt;tstamp are not zeroed.(CVE-2025-37959)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemblock: Accept allocated memory before use in memblock_double_array()\n\nWhen increasing the array size in memblock_double_array() and the slab\nis not yet available, a call to memblock_find_in_range() is used to\nreserve/allocate memory. However, the range returned may not have been\naccepted, which can result in a crash when booting an SNP guest:\n\n RIP: 0010:memcpy_orig+0x68/0x130\n Code: ...\n RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006\n RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000\n RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00\n RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000\n R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78\n R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00\n memblock_double_array+0xff/0x310\n memblock_add_range+0x1fb/0x2f0\n memblock_reserve+0x4f/0xa0\n memblock_alloc_range_nid+0xac/0x130\n memblock_alloc_internal+0x53/0xc0\n memblock_alloc_try_nid+0x3d/0xa0\n swiotlb_init_remap+0x149/0x2f0\n mem_init+0xb/0xb0\n mm_core_init+0x8f/0x350\n start_kernel+0x17e/0x5d0\n x86_64_start_reservations+0x14/0x30\n x86_64_start_kernel+0x92/0xa0\n secondary_startup_64_no_verify+0x194/0x19b\n\nMitigate this by calling accept_memory() on the memory range returned\nbefore the slab is available.\n\nPrior to v6.12, the accept_memory() interface used a \u0026apos;start\u0026apos; and \u0026apos;end\u0026apos;\nparameter instead of \u0026apos;start\u0026apos; and \u0026apos;size\u0026apos;, therefore the accept_memory()\ncall must be adjusted to specify \u0026apos;start + size\u0026apos; for \u0026apos;end\u0026apos; when applying\nto kernels prior to v6.12.(CVE-2025-37960)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix uninit-value for saddr in do_output_route4\n\nsyzbot reports for uninit-value for the saddr argument [1].\ncommit 4754957f04f5 (\u0026quot;ipvs: do not use random local source address for\ntunnels\u0026quot;) already implies that the input value of saddr\nshould be ignored but the code is still reading it which can prevent\nto connect the route. Fix it by changing the argument to ret_saddr.\n\n[1]\nBUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4167 [inline]\n slab_alloc_node mm/slub.c:4210 [inline]\n __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367\n kmalloc_noprof include/linux/slab.h:905 [inline]\n ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]\n __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)\nHardware name: Google Google Compute Engi\n---truncated---(CVE-2025-37961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: leds: fix memory leak\n\nA network restart test on a router led to an out-of-memory condition,\nwhich was traced to a memory leak in the PHY LED trigger code.\n\nThe root cause is misuse of the devm API. The registration function\n(phy_led_triggers_register) is called from phy_attach_direct, not\nphy_probe, and the unregister function (phy_led_triggers_unregister)\nis called from phy_detach, not phy_remove. This means the register and\nunregister functions can be called multiple times for the same PHY\ndevice, but devm-allocated memory is not freed until the driver is\nunbound.\n\nThis also prevents kmemleak from detecting the leak, as the devm API\ninternally stores the allocated pointer.\n\nFix this by replacing devm_kzalloc/devm_kcalloc with standard\nkzalloc/kcalloc, and add the corresponding kfree calls in the unregister\npath.(CVE-2025-37989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()\n\nThe function brcmf_usb_dl_writeimage() calls the function\nbrcmf_usb_dl_cmd() but dose not check its return value. The\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized if the\nfunction brcmf_usb_dl_cmd() fails. It is dangerous to use\nuninitialized variables in the conditions.\n\nAdd error handling for brcmf_usb_dl_cmd() to jump to error\nhandling path if the brcmf_usb_dl_cmd() fails and the\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized.\n\nImprove the error message to report more detailed error\ninformation.(CVE-2025-37990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add missing rcu read protection for procfs content\n\nWhen the procfs content is generated for a bcm_op which is in the process\nto be removed the procfs output might show unreliable data (UAF).\n\nAs the removal of bcm_op\u0026apos;s is already implemented with rcu handling this\npatch adds the missing rcu_read_lock() and makes sure the list entries\nare properly removed under rcu protection.(CVE-2025-38003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add locking for bcm_op runtime updates\n\nThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via\nhrtimer. The content and also the length of the sequence can be changed\nresp reduced at runtime where the \u0026apos;currframe\u0026apos; counter is then set to zero.\n\nAlthough this appeared to be a safe operation the updates of \u0026apos;currframe\u0026apos;\ncan be triggered from user space and hrtimer context in bcm_can_tx().\nAnderson Nascimento created a proof of concept that triggered a KASAN\nslab-out-of-bounds read access which can be prevented with a spin_lock_bh.\n\nAt the rework of bcm_can_tx() the \u0026apos;count\u0026apos; variable has been moved into\nthe protected section as this variable can be modified from both contexts\ntoo.(CVE-2025-38004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: tegra: xusb: Use a bitmask for UTMI pad power state tracking\n\nThe current implementation uses bias_pad_enable as a reference count to\nmanage the shared bias pad for all UTMI PHYs. However, during system\nsuspension with connected USB devices, multiple power-down requests for\nthe UTMI pad result in a mismatch in the reference count, which in turn\nproduces warnings such as:\n\n[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763103] Call trace:\n[ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30\n[ 237.763110] phy_power_off+0x48/0x100\n[ 237.763113] tegra_xusb_enter_elpg+0x204/0x500\n[ 237.763119] tegra_xusb_suspend+0x48/0x140\n[ 237.763122] platform_pm_suspend+0x2c/0xb0\n[ 237.763125] dpm_run_callback.isra.0+0x20/0xa0\n[ 237.763127] __device_suspend+0x118/0x330\n[ 237.763129] dpm_suspend+0x10c/0x1f0\n[ 237.763130] dpm_suspend_start+0x88/0xb0\n[ 237.763132] suspend_devices_and_enter+0x120/0x500\n[ 237.763135] pm_suspend+0x1ec/0x270\n\nThe root cause was traced back to the dynamic power-down changes\nintroduced in commit a30951d31b25 (\u0026quot;xhci: tegra: USB2 pad power controls\u0026quot;),\nwhere the UTMI pad was being powered down without verifying its current\nstate. This unbalanced behavior led to discrepancies in the reference\ncount.\n\nTo rectify this issue, this patch replaces the single reference counter\nwith a bitmask, renamed to utmi_pad_enabled. Each bit in the mask\ncorresponds to one of the four USB2 PHYs, allowing us to track each pad\u0026apos;s\nenablement status individually.\n\nWith this change:\n - The bias pad is powered on only when the mask is clear.\n - Each UTMI pad is powered on or down based on its corresponding bit\n in the mask, preventing redundant operations.\n - The overall power state of the shared bias pad is maintained\n correctly during suspend/resume cycles.\n\nThe mutex used to prevent race conditions during UTMI pad enable/disable\noperations has been moved from the tegra186_utmi_bias_pad_power_on/off\nfunctions to the parent functions tegra186_utmi_pad_power_on/down. This\nchange ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices\n\nThe driver only offloads neighbors that are constructed on top of net\ndevices registered by it or their uppers (which are all Ethernet). The\ndevice supports GRE encapsulation and decapsulation of forwarded\ntraffic, but the driver will not offload dummy neighbors constructed on\ntop of GRE net devices as they are not uppers of its net devices:\n\n # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1\n # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 NOARP\n\n(Note that the neighbor is not marked with \u0026apos;offload\u0026apos;)\n\nWhen the driver is reloaded and the existing configuration is replayed,\nthe driver does not perform the same check regarding existing neighbors\nand offloads the previously added one:\n\n # devlink dev reload pci/0000:01:00.0\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 offload NOARP\n\nIf the neighbor is later deleted, the driver will ignore the\nnotification (given the GRE net device is not its upper) and will\ntherefore keep referencing freed memory, resulting in a use-after-free\n[1] when the net device is deleted:\n\n # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1\n # ip link del dev gre1\n\nFix by skipping neighbor replay if the net device for which the replay\nis performed is not our upper.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200\nRead of size 8 at addr ffff888155b0e420 by task ip/2282\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6f/0x350\n print_report+0x108/0x205\n kasan_report+0xdf/0x110\n mlxsw_sp_neigh_entry_update+0x1ea/0x200\n mlxsw_sp_router_rif_gone_sync+0x2a8/0x440\n mlxsw_sp_rif_destroy+0x1e9/0x750\n mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0\n mlxsw_sp_router_netdevice_event+0x3ac/0x15e0\n notifier_call_chain+0xca/0x150\n call_netdevice_notifiers_info+0x7f/0x100\n unregister_netdevice_many_notify+0xc8c/0x1d90\n rtnl_dellink+0x34e/0xa50\n rtnetlink_rcv_msg+0x6fb/0xb70\n netlink_rcv_skb+0x131/0x360\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Disable MACsec offload for uplink representor profile\n\nMACsec offload is not supported in switchdev mode for uplink\nrepresentors. When switching to the uplink representor profile, the\nMACsec offload feature must be cleared from the netdevice\u0026apos;s features.\n\nIf left enabled, attempts to add offloads result in a null pointer\ndereference, as the uplink representor does not support MACsec offload\neven though the feature bit remains set.\n\nClear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().\n\nKernel log:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]\nCPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__mutex_lock+0x128/0x1dd0\nCode: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff\nRSP: 0018:ffff888147a4f160 EFLAGS: 00010206\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078\nRBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000\nFS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x3d/0xa0\n ? exc_general_protection+0x144/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? __mutex_lock+0x128/0x1dd0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mutex_lock_io_nested+0x1ae0/0x1ae0\n ? lock_acquire+0x1c2/0x530\n ? macsec_upd_offload+0x145/0x380\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n ? __kasan_kmalloc+0x77/0x90\n ? __kmalloc_noprof+0x249/0x6b0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]\n macsec_update_offload+0x26c/0x820\n ? macsec_set_mac_address+0x4b0/0x4b0\n ? lockdep_hardirqs_on_prepare+0x284/0x400\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n macsec_upd_offload+0x2c8/0x380\n ? macsec_update_offload+0x820/0x820\n ? __nla_parse+0x22/0x30\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240\n genl_family_rcv_msg_doit+0x1cc/0x2a0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240\n ? cap_capable+0xd4/0x330\n genl_rcv_msg+0x3ea/0x670\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? macsec_update_offload+0x820/0x820\n netlink_rcv_skb+0x12b/0x390\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? netlink_ack+0xd80/0xd80\n ? rwsem_down_read_slowpath+0xf90/0xf90\n ? netlink_deliver_tap+0xcd/0xac0\n ? netlink_deliver_tap+0x155/0xac0\n ? _copy_from_iter+0x1bb/0x12c0\n genl_rcv+0x24/0x40\n netlink_unicast+0x440/0x700\n ? netlink_attachskb+0x760/0x760\n ? lock_acquire+0x1c2/0x530\n ? __might_fault+0xbb/0x170\n netlink_sendmsg+0x749/0xc10\n ? netlink_unicast+0x700/0x700\n ? __might_fault+0xbb/0x170\n ? netlink_unicast+0x700/0x700\n __sock_sendmsg+0xc5/0x190\n ____sys_sendmsg+0x53f/0x760\n ? import_iovec+0x7/0x10\n ? kernel_sendmsg+0x30/0x30\n ? __copy_msghdr+0x3c0/0x3c0\n ? filter_irq_stacks+0x90/0x90\n ? stack_depot_save_flags+0x28/0xa30\n ___sys_sen\n---truncated---(CVE-2025-38020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix \u0026quot;KASAN: slab-use-after-free Read in ib_register_device\u0026quot; problem\n\nCall Trace:\n\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n strlen+0x93/0xa0 lib/string.c:420\n __fortify_strlen include/linux/fortify-string.h:268 [inline]\n get_kobj_path_length lib/kobject.c:118 [inline]\n kobject_get_path+0x3f/0x2a0 lib/kobject.c:158\n kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545\n ib_register_device drivers/infiniband/core/device.c:1472 [inline]\n ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393\n rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552\n rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225\n nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796\n rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195\n rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmsg+0x16d/0x220 net/socket.c:2652\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThis problem is similar to the problem that the\ncommit 1d6a9e7449e2 (\u0026quot;RDMA/core: Fix use-after-free when rename device name\u0026quot;)\nfixes.\n\nThe root cause is: the function ib_device_rename() renames the name with\nlock. But in the function kobject_uevent(), this name is accessed without\nlock protection at the same time.\n\nThe solution is to add the lock protection when this name is accessed in\nthe function kobject_uevent().(CVE-2025-38022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.(CVE-2025-38024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled\n\nWhen attempting to enable MQPRIO while HTB offload is already\nconfigured, the driver currently returns `-EINVAL` and triggers a\n`WARN_ON`, leading to an unnecessary call trace.\n\nUpdate the code to handle this case more gracefully by returning\n`-EOPNOTSUPP` instead, while also providing a helpful user message.(CVE-2025-38039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn\n\nThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can\nrun on multiple platforms having different DMA architectures.\nOn some platforms there can be one FDQ for all flows in the RX channel\nwhile for others there is a separate FDQ for each flow in the RX channel.\n\nSo far we have been relying on the skip_fdq argument of\nk3_udma_glue_reset_rx_chn().\n\nInstead of relying on the user to provide this information, infer it\nbased on DMA architecture during k3_udma_glue_request_rx_chn() and save it\nin an internal flag \u0026apos;single_fdq\u0026apos;. Use that flag at\nk3_udma_glue_reset_rx_chn() to deicide if the FDQ needs\nto be cleared for every flow or just for flow 0.\n\nFixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.\n\n\u0026gt; ip link set eth1 down\n\u0026gt; ip link set eth0 down\n\u0026gt; ethtool -L eth0 rx 8\n\u0026gt; ip link set eth0 up\n\u0026gt; modprobe -r ti_am65_cpsw_nuss\n\n[ 103.045726] ------------[ cut here ]------------\n[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000\n[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas\np drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r\nfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool]\n[ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011\n[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)\n[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.154709] sp : ffff8000826ebbc0\n[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000\n[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0\n[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88\n[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000\n[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde\n[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000\n[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20\n[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100\n[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000\n[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000\n[ 103.229274] Call trace:\n[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)\n[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss]\n[ 103.244942] devm_action_release+0x14/0x20\n[ 103.249040] release_nodes+0x3c/0x68\n[ 103.252610] devres_release_all+0x8c/0xdc\n[ 103.256614] device_unbind_cleanup+0x18/0x60\n[ 103.260876] device_release_driver_internal+0xf8/0x178\n[ 103.266004] driver_detach+0x50/0x9c\n[ 103.269571] bus_remove_driver+0x6c/0xbc\n[ 103.273485] driver_unregister+0x30/0x60\n[ 103.277401] platform_driver_unregister+0x14/0x20\n[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss]\n[ 103.288620] __arm64_sys_delete_module+0x17c/0x25c\n[ 103.293404] invoke_syscall+0x44/0x100\n[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0\n[ 103.301845] do_el0_svc+0x1c/0x28\n[ 103.305155] el0_svc+0x28/0x98\n---truncated---(CVE-2025-38042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: set device_caps for 417\n\nThe video_device for the MPEG encoder did not set device_caps.\n\nAdd this, otherwise the video device can\u0026apos;t be registered (you get a\nWARN_ON instead).\n\nNot seen before since currently 417 support is disabled, but I found\nthis while experimenting with it.(CVE-2025-38044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: fix skb leaks\n\nA few error paths are missing a kfree_skb.(CVE-2025-38057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: prevent BUG_ON by blocking retries on failed device resumes\n\nA cache device failing to resume due to mapping errors should not be\nretried, as the failure leaves a partially initialized policy object.\nRepeating the resume operation risks triggering BUG_ON when reloading\ncache mappings into the incomplete policy object.\n\nReproduce steps:\n\n1. create a cache metadata consisting of 512 or more cache blocks,\n with some mappings stored in the first array block of the mapping\n array. Here we use cache_restore v1.0 to build the metadata.\n\ncat \u0026lt;\u0026lt;EOF \u0026gt;\u0026gt; cmeta.xml\n\u0026lt;superblock uuid=\u0026quot;\u0026quot; block_size=\u0026quot;128\u0026quot; nr_cache_blocks=\u0026quot;512\u0026quot; \\\npolicy=\u0026quot;smq\u0026quot; hint_width=\u0026quot;4\u0026quot;\u0026gt;\n \u0026lt;mappings\u0026gt;\n \u0026lt;mapping cache_block=\u0026quot;0\u0026quot; origin_block=\u0026quot;0\u0026quot; dirty=\u0026quot;false\u0026quot;/\u0026gt;\n \u0026lt;/mappings\u0026gt;\n\u0026lt;/superblock\u0026gt;\nEOF\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ncache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2\ndmsetup remove cmeta\n\n2. wipe the second array block of the mapping array to simulate\n data degradations.\n\nmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\nablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\ndd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock\n\n3. try bringing up the cache device. The resume is expected to fail\n due to the broken array block.\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndmsetup create cache --notable\ndmsetup load cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\ndmsetup resume cache\n\n4. try resuming the cache again. An unexpected BUG_ON is triggered\n while loading cache mappings.\n\ndmsetup resume cache\n\nKernel logs:\n\n(snip)\n------------[ cut here ]------------\nkernel BUG at drivers/md/dm-cache-policy-smq.c:752!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3\nRIP: 0010:smq_load_mapping+0x3e5/0x570\n\nFix by disallowing resume operations for devices that failed the\ninitial attempt.(CVE-2025-38066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race\n\nhuge_pmd_unshare() drops a reference on a page table that may have\npreviously been shared across processes, potentially turning it into a\nnormal page table used in another process in which unrelated VMAs can\nafterwards be installed.\n\nIf this happens in the middle of a concurrent gup_fast(), gup_fast() could\nend up walking the page tables of another process. While I don\u0026apos;t see any\nway in which that immediately leads to kernel memory corruption, it is\nreally weird and unexpected.\n\nFix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),\njust like we do in khugepaged when removing page tables for a THP\ncollapse.(CVE-2025-38085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix use-after-free in taprio_dev_notifier\n\nSince taprio\u2019s taprio_dev_notifier() isn\u2019t protected by an\nRCU read-side critical section, a race with advance_sched()\ncan lead to a use-after-free.\n\nAdding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: remove encap socket caching to avoid reference leak\n\nThe current scheme for caching the encap socket can lead to reference\nleaks when we try to delete the netns.\n\nThe reference chain is: xfrm_state -\u0026gt; enacp_sk -\u0026gt; netns\n\nSince the encap socket is a userspace socket, it holds a reference on\nthe netns. If we delete the espintcp state (through flush or\nindividual delete) before removing the netns, the reference on the\nsocket is dropped and the netns is correctly deleted. Otherwise, the\nnetns may not be reachable anymore (if all processes within the ns\nhave terminated), so we cannot delete the xfrm state to drop its\nreference on the socket.\n\nThis patch results in a small (~2% in my tests) performance\nregression.\n\nA GC-type mechanism could be added for the socket cache, to clear\nreferences if the state hasn\u0026apos;t been used \u0026quot;recently\u0026quot;, but it\u0026apos;s a lot\nmore complex than just not caching the socket.(CVE-2025-38097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: Fix use-after-free in page_pool_recycle_in_ring\n\nsyzbot reported a uaf in page_pool_recycle_in_ring:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\nRead of size 8 at addr ffff8880286045a0 by task syz.0.284/6943\n\nCPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]\n _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]\n page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]\n page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826\n page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]\n page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]\n napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036\n skb_pp_recycle net/core/skbuff.c:1047 [inline]\n skb_free_head net/core/skbuff.c:1094 [inline]\n skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125\n skb_release_all net/core/skbuff.c:1190 [inline]\n __kfree_skb net/core/skbuff.c:1204 [inline]\n sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242\n kfree_skb_reason include/linux/skbuff.h:1263 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]\n\nroot cause is:\n\npage_pool_recycle_in_ring\n ptr_ring_produce\n spin_lock(\u0026amp;r-\u0026gt;producer_lock);\n WRITE_ONCE(r-\u0026gt;queue[r-\u0026gt;producer++], ptr)\n //recycle last page to pool\n\t\t\t\tpage_pool_release\n\t\t\t\t page_pool_scrub\n\t\t\t\t page_pool_empty_ring\n\t\t\t\t ptr_ring_consume\n\t\t\t\t page_pool_return_page //release all page\n\t\t\t\t __page_pool_destroy\n\t\t\t\t free_percpu(pool-\u0026gt;recycle_stats);\n\t\t\t\t free(pool) //free\n\n spin_unlock(\u0026amp;r-\u0026gt;producer_lock); //pool-\u0026gt;ring uaf read\n recycle_stat_inc(pool, ring);\n\npage_pool can be free while page pool recycle the last page in ring.\nAdd producer-lock barrier to page_pool_release to prevent the page\npool from being free before all pages have been recycled.\n\nrecycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not\nenabled, which will trigger Wempty-body build warning. Add definition\nfor pool stat macro to fix warning.(CVE-2025-38129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u0026gt;sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0026apos;\u0026apos;\u0026apos;\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u0026gt;release() -\u0026gt; sock_map_close()\n sk_socket-\u0026gt;ops = NULL\n free(socket)\n sock-\u0026gt;ops-\u0026gt;sendmsg\n ^\n panic here\n\u0026apos;\u0026apos;\u0026apos;\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0026apos;\u0026apos;\u0026apos;\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u0026lt;=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0026apos;\u0026apos;\u0026apos;\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0026apos;t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0026apos;\u0026apos;\u0026apos;\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0026apos;\u0026apos;\u0026apos;(CVE-2025-38154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix panic when calling skb_linearize\n\nThe panic can be reproduced by executing the command:\n./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000\n\nThen a kernel panic was captured:\n\u0026apos;\u0026apos;\u0026apos;\n[ 657.460555] kernel BUG at net/core/skbuff.c:2178!\n[ 657.462680] Tainted: [W]=WARN\n[ 657.463287] Workqueue: events sk_psock_backlog\n...\n[ 657.469610] \u0026lt;TASK\u0026gt;\n[ 657.469738] ? die+0x36/0x90\n[ 657.469916] ? do_trap+0x1d0/0x270\n[ 657.470118] ? pskb_expand_head+0x612/0xf40\n[ 657.470376] ? pskb_expand_head+0x612/0xf40\n[ 657.470620] ? do_error_trap+0xa3/0x170\n[ 657.470846] ? pskb_expand_head+0x612/0xf40\n[ 657.471092] ? handle_invalid_op+0x2c/0x40\n[ 657.471335] ? pskb_expand_head+0x612/0xf40\n[ 657.471579] ? exc_invalid_op+0x2d/0x40\n[ 657.471805] ? asm_exc_invalid_op+0x1a/0x20\n[ 657.472052] ? pskb_expand_head+0xd1/0xf40\n[ 657.472292] ? pskb_expand_head+0x612/0xf40\n[ 657.472540] ? lock_acquire+0x18f/0x4e0\n[ 657.472766] ? find_held_lock+0x2d/0x110\n[ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10\n[ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470\n[ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10\n[ 657.473826] __pskb_pull_tail+0xfd/0x1d20\n[ 657.474062] ? __kasan_slab_alloc+0x4e/0x90\n[ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510\n[ 657.475392] ? __kasan_kmalloc+0xaa/0xb0\n[ 657.476010] sk_psock_backlog+0x5cf/0xd70\n[ 657.476637] process_one_work+0x858/0x1a20\n\u0026apos;\u0026apos;\u0026apos;\n\nThe panic originates from the assertion BUG_ON(skb_shared(skb)) in\nskb_linearize(). A previous commit(see Fixes tag) introduced skb_get()\nto avoid race conditions between skb operations in the backlog and skb\nrelease in the recvmsg path. However, this caused the panic to always\noccur when skb_linearize is executed.\n\nThe \u0026quot;--rx-strp 100000\u0026quot; parameter forces the RX path to use the strparser\nmodule which aggregates data until it reaches 100KB before calling sockmap\nlogic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.\n\nTo fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.\n\n\u0026apos;\u0026apos;\u0026apos;\nsk_psock_backlog:\n sk_psock_handle_skb\n skb_get(skb) \u0026lt;== we move it into \u0026apos;sk_psock_skb_ingress_enqueue\u0026apos;\n sk_psock_skb_ingress____________\n \u2193\n |\n | \u2192 sk_psock_skb_ingress_self\n | sk_psock_skb_ingress_enqueue\nsk_psock_verdict_apply_________________\u2191 skb_linearize\n\u0026apos;\u0026apos;\u0026apos;\n\nNote that for verdict_apply path, the skb_get operation is unnecessary so\nwe add \u0026apos;take_ref\u0026apos; param to control it\u0026apos;s behavior.(CVE-2025-38165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix ktls panic with sockmap\n\n[ 2172.936997] ------------[ cut here ]------------\n[ 2172.936999] kernel BUG at lib/iov_iter.c:629!\n......\n[ 2172.944996] PKRU: 55555554\n[ 2172.945155] Call Trace:\n[ 2172.945299] \u0026lt;TASK\u0026gt;\n[ 2172.945428] ? die+0x36/0x90\n[ 2172.945601] ? do_trap+0xdd/0x100\n[ 2172.945795] ? iov_iter_revert+0x178/0x180\n[ 2172.946031] ? iov_iter_revert+0x178/0x180\n[ 2172.946267] ? do_error_trap+0x7d/0x110\n[ 2172.946499] ? iov_iter_revert+0x178/0x180\n[ 2172.946736] ? exc_invalid_op+0x50/0x70\n[ 2172.946961] ? iov_iter_revert+0x178/0x180\n[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20\n[ 2172.947446] ? iov_iter_revert+0x178/0x180\n[ 2172.947683] ? iov_iter_revert+0x5c/0x180\n[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840\n[ 2172.948206] tls_sw_sendmsg+0x52/0x80\n[ 2172.948420] ? inet_sendmsg+0x1f/0x70\n[ 2172.948634] __sys_sendto+0x1cd/0x200\n[ 2172.948848] ? find_held_lock+0x2b/0x80\n[ 2172.949072] ? syscall_trace_enter+0x140/0x270\n[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170\n[ 2172.949595] ? find_held_lock+0x2b/0x80\n[ 2172.949817] ? syscall_trace_enter+0x140/0x270\n[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190\n[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0\n[ 2172.951036] __x64_sys_sendto+0x24/0x30\n[ 2172.951382] do_syscall_64+0x90/0x170\n......\n\nAfter calling bpf_exec_tx_verdict(), the size of msg_pl-\u0026gt;sg may increase,\ne.g., when the BPF program executes bpf_msg_push_data().\n\nIf the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,\nit will return -ENOSPC and attempt to roll back to the non-zero copy\nlogic. However, during rollback, msg-\u0026gt;msg_iter is reset, but since\nmsg_pl-\u0026gt;sg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n\u0026apos;\u0026apos;\u0026apos;\niov_iter_revert(\u0026amp;msg-\u0026gt;msg_iter, msg_pl-\u0026gt;sg.size - orig_size);\n\u0026apos;\u0026apos;\u0026apos;\n\nThe changes in this commit are based on the following considerations:\n\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n\n2. We can not calculate the correct number of bytes to revert msg_iter.\n\nAssume the original data is \u0026quot;abcdefgh\u0026quot; (8 bytes), and after 3 pushes\nby the BPF program, it becomes 11-byte data: \u0026quot;abc?de?fgh?\u0026quot;.\nThen, we set cork_bytes to 6, which means the first 6 bytes have been\nprocessed, and the remaining 5 bytes \u0026quot;?fgh?\u0026quot; will be cached until the\nlength meets the cork_bytes requirement.\n\nHowever, some data in \u0026quot;?fgh?\u0026quot; is not within \u0026apos;sg-\u0026gt;msg_iter\u0026apos;\n(but in msg_pl instead), especially the data \u0026quot;?\u0026quot; we pushed.\n\nSo it doesn\u0026apos;t seem as simple as just reverting through an offset of\nmsg_iter.\n\n3. For non-TLS sockets in tcp_bpf_sendmsg, when a \u0026quot;cork\u0026quot; situation occurs,\nthe user-space send() doesn\u0026apos;t return an error, and the returned length is\nthe same as the input length parameter, even if some data is cached.\n\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n\u0026apos;\u0026apos;\u0026apos;\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n\u0026apos;\u0026apos;\u0026apos;\n\nSo it\u0026apos;s ok to just return \u0026apos;copied\u0026apos; without error when a \u0026quot;cork\u0026quot; situation\noccurs.(CVE-2025-38166)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush\n\nIn KVM guests with Hyper-V hypercalls enabled, the hypercalls\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX\nallow a guest to request invalidation of portions of a virtual TLB.\nFor this, the hypercall parameter includes a list of GVAs that are supposed\nto be invalidated.\n\nHowever, when non-canonical GVAs are passed, there is currently no\nfiltering in place and they are eventually passed to checked invocations of\nINVVPID on Intel / INVLPGA on AMD. While AMD\u0026apos;s INVLPGA silently ignores\nnon-canonical addresses (effectively a no-op), Intel\u0026apos;s INVVPID explicitly\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():\n\n invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000\n WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482\n invvpid_error+0x91/0xa0 [kvm_intel]\n Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse\n CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)\n RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]\n Call Trace:\n vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]\n kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]\n\nHyper-V documents that invalid GVAs (those that are beyond a partition\u0026apos;s\nGVA space) are to be ignored. While not completely clear whether this\nruling also applies to non-canonical GVAs, it is likely fine to make that\nassumption, and manual testing on Azure confirms \u0026quot;real\u0026quot; Hyper-V interprets\nthe specification in the same way.\n\nSkip non-canonical GVAs when processing the list of address to avoid\ntripping the INVVPID failure. Alternatively, KVM could filter out \u0026quot;bad\u0026quot;\nGVAs before inserting into the FIFO, but practically speaking the only\ndownside of pushing validation to the final processing is that doing so\nis suboptimal for the guest, and no well-behaved guest will request TLB\nflushes for non-canonical addresses.(CVE-2025-38351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks\n\nAfter retrieving WMI data blocks in sysfs callbacks, check for the\nvalidity of them before dereferencing their content.(CVE-2025-38412)\n\nIn the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net-\u0026gt;xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net-\u0026gt;collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)\n\nIn the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: \u0026apos;dma\u0026apos; and \u0026apos;page_dma\u0026apos;. However, only \u0026apos;page_dma\u0026apos; was actually initialized and used to program the Rx descriptor. But \u0026apos;dma\u0026apos; was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized \u0026apos;dma\u0026apos; was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)\n\nIn the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 \u0026amp; 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Prevent VMA split of buffer mappings\n\nThe perf mmap code is careful about mmap()\u0026apos;ing the user page with the\nringbuffer and additionally the auxiliary buffer, when the event supports\nit. Once the first mapping is established, subsequent mapping have to use\nthe same offset and the same size in both cases. The reference counting for\nthe ringbuffer and the auxiliary buffer depends on this being correct.\n\nThough perf does not prevent that a related mapping is split via mmap(2),\nmunmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,\nwhich take reference counts, but then the subsequent perf_mmap_close()\ncalls are not longer fulfilling the offset and size checks. This leads to\nreference count leaks.\n\nAs perf already has the requirement for subsequent mappings to match the\ninitial mapping, the obvious consequence is that VMA splits, caused by\nresizing of a mapping or partial unmapping, have to be prevented.\n\nImplement the vm_operations_struct::may_split() callback and return\nunconditionally -EINVAL.\n\nThat ensures that the mapping offsets and sizes cannot be changed after the\nfact. Remapping to a different fixed address with the same size is still\npossible as it takes the references for the new mapping and drops those of\nthe old mapping.(CVE-2025-38563)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbenet: fix BUG when creating VFs\n\nbenet crashes as soon as SRIOV VFs are created:\n\n kernel BUG at mm/vmalloc.c:3457!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)\n [...]\n RIP: 0010:vunmap+0x5f/0x70\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __iommu_dma_free+0xe8/0x1c0\n be_cmd_set_mac_list+0x3fe/0x640 [be2net]\n be_cmd_set_mac+0xaf/0x110 [be2net]\n be_vf_eth_addr_config+0x19f/0x330 [be2net]\n be_vf_setup+0x4f7/0x990 [be2net]\n be_pci_sriov_configure+0x3a1/0x470 [be2net]\n sriov_numvfs_store+0x20b/0x380\n kernfs_fop_write_iter+0x354/0x530\n vfs_write+0x9b9/0xf60\n ksys_write+0xf3/0x1d0\n do_syscall_64+0x8c/0x3d0\n\nbe_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.\nFix it by freeing only after the lock has been released.(CVE-2025-38569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix double destruction of rsv_qp\n\nrsv_qp may be double destroyed in error flow, first in free_mr_init(),\nand then in hns_roce_exit(). Fix it by moving the free_mr_init() call\ninto hns_roce_v2_init().\n\nlist_del corruption, ffff589732eb9b50-\u0026gt;next is LIST_POISON1 (dead000000000100)\nWARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240\n...\nCall trace:\n __list_del_entry_valid+0x148/0x240\n hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]\n hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]\n hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]\n free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]\n hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]\n hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]\n __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]\n hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]\n hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]\n hclge_notify_roce_client+0x6c/0x160 [hclge]\n hclge_reset_rebuild+0x150/0x5c0 [hclge]\n hclge_reset+0x10c/0x140 [hclge]\n hclge_reset_subtask+0x80/0x104 [hclge]\n hclge_reset_service_task+0x168/0x3ac [hclge]\n hclge_service_task+0x50/0x100 [hclge]\n process_one_work+0x250/0x9a0\n worker_thread+0x324/0x990\n kthread+0x190/0x210\n ret_from_fork+0x10/0x18(CVE-2025-38582)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmci: Prevent the dispatching of uninitialized payloads\n\nThe reproducer executes the host\u0026apos;s unlocked_ioctl call in two different\ntasks. When init_context fails, the struct vmci_event_ctx is not fully\ninitialized when executing vmci_datagram_dispatch() to send events to all\nvm contexts. This affects the datagram taken from the datagram queue of\nits context by another task, because the datagram payload is not initialized\naccording to the size payload_size, which causes the kernel data to leak\nto the user space.\n\nBefore dispatching the datagram, and before setting the payload content,\nexplicitly set the payload content to 0 to avoid data leakage caused by\nincomplete payload initialization.(CVE-2025-38611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 (\u0026quot;pinmux: Use sequential access to access\ndesc-\u0026gt;pinmux data\u0026quot;) tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc-\u0026gt;mux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n cpu0 (process A) cpu1 (process B)\n\n pin_request() { pin_free() {\n\n mutex_lock()\n desc-\u0026gt;mux_usecount--; //becomes 0\n ..\n mutex_unlock()\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_usecount++; // becomes 1\n desc-\u0026gt;mux_owner = owner;\n mutex_unlock(desc-\u0026gt;mux)\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_owner = NULL;\n mutex_unlock(desc-\u0026gt;mux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.(CVE-2025-38632)\n\nIn the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro\u0026apos;s suggestion, it was fixed in the same manner.(CVE-2025-38653)\n\nIn the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)",
"id": "OESA-2025-2120",
"modified": "2026-08-06T11:09:12Z",
"published": "2025-09-05T11:09:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37885"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37912"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37989"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38066"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38166"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38412"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38500"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38563"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38569"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38632"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38671"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21678",
"CVE-2025-21723",
"CVE-2025-21864",
"CVE-2025-21947",
"CVE-2025-21955",
"CVE-2025-22007",
"CVE-2025-22021",
"CVE-2025-22056",
"CVE-2025-22057",
"CVE-2025-22063",
"CVE-2025-22064",
"CVE-2025-22086",
"CVE-2025-22089",
"CVE-2025-22106",
"CVE-2025-37749",
"CVE-2025-37752",
"CVE-2025-37772",
"CVE-2025-37789",
"CVE-2025-37794",
"CVE-2025-37829",
"CVE-2025-37834",
"CVE-2025-37859",
"CVE-2025-37875",
"CVE-2025-37879",
"CVE-2025-37885",
"CVE-2025-37909",
"CVE-2025-37911",
"CVE-2025-37912",
"CVE-2025-37945",
"CVE-2025-37959",
"CVE-2025-37960",
"CVE-2025-37961",
"CVE-2025-37989",
"CVE-2025-37990",
"CVE-2025-38003",
"CVE-2025-38004",
"CVE-2025-38010",
"CVE-2025-38019",
"CVE-2025-38020",
"CVE-2025-38022",
"CVE-2025-38024",
"CVE-2025-38039",
"CVE-2025-38042",
"CVE-2025-38044",
"CVE-2025-38057",
"CVE-2025-38066",
"CVE-2025-38085",
"CVE-2025-38087",
"CVE-2025-38097",
"CVE-2025-38129",
"CVE-2025-38154",
"CVE-2025-38165",
"CVE-2025-38166",
"CVE-2025-38201",
"CVE-2025-38351",
"CVE-2025-38412",
"CVE-2025-38500",
"CVE-2025-38533",
"CVE-2025-38540",
"CVE-2025-38563",
"CVE-2025-38569",
"CVE-2025-38582",
"CVE-2025-38611",
"CVE-2025-38632",
"CVE-2025-38653",
"CVE-2025-38671"
]
}
oesa-2025-2121
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
gtp: Destroy device along with udp socket's netns dismantle.
gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.
Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]
In this example, gtp0 is created in ns2, and the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1
Let's link the device to the socket's netns instead.
Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.
[0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) _syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) _sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated---(CVE-2025-21678)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix possible crash when setting up bsg fails
If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value. Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)" will not be satisfied, preventing execution from entering bsg_remove_queue(), which could lead to the following crash:
BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace: <TASK> mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr] mpi3mr_remove+0x6f/0x340 [mpi3mr] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19d/0x220 unbind_store+0xa4/0xb0 kernfs_fop_write_iter+0x11f/0x200 vfs_write+0x1fc/0x3e0 ksys_write+0x67/0xe0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)
In the Linux kernel, the following vulnerability has been resolved:
tcp: drop secpath at the same time as we currently drop dst
Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns
The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free'd by skb_attempt_defer_free.
The problem happens when we defer freeing an skb (push it on one CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don't expect at this point.
We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.(CVE-2025-21864)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix type confusion via race condition when using ipc_msg_send_request
req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.(CVE-2025-21947)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: prevent connection release during oplock break notification
ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.(CVE-2025-21955)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix error code in chan_alloc_skb_cb()
The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent.
However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as
pods' addresses are in the fd00::/8 ULA subnet and need to be replaced
with the node's external address. Cilium leverages Envoy to enforce L7
policies, and Envoy uses transparent sockets. Cilium inserts an iptables
prerouting rule that matches on -m socket --transparent and redirects
the packets to localhost, but it fails to match SNATed IPv6 packets due
to that missing conntrack lookup.(CVE-2025-22021)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_tunnel: fix geneve_opt type confusion addition
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] _syssendmsg+0x409/0x450 [ 7.002391] _sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse and dump code.(CVE-2025-22056)
In the Linux kernel, the following vulnerability has been resolved:
net: decrease cached dst counters in dst_release
Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:
Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30
Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.(CVE-2025-22057)
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed:
sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.
This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.(CVE-2025-22063)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: don't unregister hook when table is dormant
When nf_tables_updchain encounters an error, hook registration needs to be rolled back.
This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive).
Just move the assignment into the registration block.(CVE-2025-22064)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.
The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number.
Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 </TASK>(CVE-2025-22086)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Don't expose hw_counters outside of init net namespace
Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one:
[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: error_code(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] <TASK> [42021.953842] [<ffffffff86c58674>] ? show_regs+0x64/0x70 [42021.959030] [<ffffffff86c58468>] ? __die+0x78/0xc0 [42021.963874] [<ffffffff86c9ef75>] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [<ffffffff87674b92>] ? exc_page_fault+0x1a2/0x3c0 [42021.975549] [<ffffffff87801326>] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [<ffffffffc0775680>] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [<ffffffffc077564e>] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [<ffffffff86ac7f8e>] dev_attr_show+0x1e/0x50 [42022.000803] [<ffffffff86a3eeb1>] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [<ffffffff86a11134>] seq_read_iter+0xf4/0x410 [42022.011954] [<ffffffff869f4b2e>] vfs_read+0x16e/0x2f0 [42022.017058] [<ffffffff869f50ee>] ksys_read+0x6e/0xe0 [42022.022073] [<ffffffff8766f1ca>] do_syscall_64+0x6a/0xa0 [42022.027441] [<ffffffff8780013b>] entry_SYSCALL_64_after_hwframe+0x78/0xe2
The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*
The panic occurs because of casting the device pointer into an ib_device pointer using container_of() in hw_stat_device_show() is wrong and leads to a memory corruption.
However the real problem is that hw counters should never been exposed outside of the non-init net namespace.
Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization.
With this fix applied hw_counters are not available in a non-init net namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters
ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: unregister xdp rxq info in the reset path
vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace.
Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0
This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)
In the Linux kernel, the following vulnerability has been resolved:
net: ppp: Add bound checking for skb data on ppp_sync_txmung
Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets.
When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 }
from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,
it is not safe to access data[2].
[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: move the limit validation
It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed.
Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations:
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
This fixes the following syzkaller reported crash:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix workqueue crash in cma_netevent_work_handler
struct rdma_cm_id has member "struct work_struct net_work" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq.
Below crash[1] can occur if more than one call to cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue.
Also drgn analysis [2] indicates the work item was likely overwritten.
Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread.
[1] Trimmed crash stack:
BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 =============================================
[2] drgn crash analysis:
>>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9)
Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
>>> trace[8]["work"] (struct work_struct )0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head )0xffff924d075924c0, .prev = (struct list_head )0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, }
Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *)<absent>
In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work);
and get_work_pwq() is: static struct pool_workqueue get_work_pwq(struct work_struct work) { unsigned long data = atomic_long_read(&work->data);
if (data & WORK_STRUCT_PWQ)
return work_struct_pwq(data);
else
return NULL;
}
WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4)
But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================(CVE-2025-37772)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix nested key length validation in the set() action
It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Purge vif txq in ieee80211_do_stop()
After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state.
Because vif.drv_priv is now cleared in this function, this could lead to driver crash.
For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below.
Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158
To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()
cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37829)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: don't try to reclaim hwpoison folio
Syzkaller reports a bug as follows:
Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20
I can reproduce this issue with the following steps:
1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.
2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.
3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared.
To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list.(CVE-2025-37834)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: avoid infinite loop to schedule delayed worker
We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1].
Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally.
This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry().
[1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)
In the Linux kernel, the following vulnerability has been resolved:
igc: fix PTM cycle trigger logic
Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction.
The issue can be reproduced with the following:
$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m
Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue.
PHC2SYS exits with:
"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails
This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM.
The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle.
When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump.
With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)
In the Linux kernel, the following vulnerability has been resolved:
9p/net: fix improper handling of bogus negative read/write replies
In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed.
Make variables unsigned to avoid this problem.
The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)(CVE-2025-37879)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reset IRTE to host control if new route isn't postable
Restore an IRTE back to host control (remapped or posted MSI mode) if the new GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.
The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.(CVE-2025-37885)
In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: Fix memleak issue when GSO enabled
Always map the skb to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak(CVE-2025-37909)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix out-of-bound memcpy() during ethtool -w
When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption:
BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80
...
This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf.
In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information.
This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.(CVE-2025-37911)
In the Linux kernel, the following vulnerability has been resolved:
ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()
As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI pointer values"), we need to perform a null pointer check on the return value of ice_get_vf_vsi() before using it.(CVE-2025-37912)
In the Linux kernel, the following vulnerability has been resolved:
sch_htb: make htb_qlen_notify() idempotent
htb_qlen_notify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fq_codel_dequeue().
Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life.(CVE-2025-37932)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY
DSA has 2 kinds of drivers:
- Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
- Those who don't: all others. The above methods should be optional.
For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.
Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered:
WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&
phydev->state != PHY_UP);
because the PHY state machine is running.
It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user.
The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs.
mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible.
This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected:
$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c
Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.
Thus, for the situation where the PM is not managed b ---truncated---(CVE-2025-37945)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Scrub packet on bpf_redirect_peer
When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace.
As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function.
NETNS MARK IFACE TUPLE FUNC
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive
.active_extensions = (__u8)2,
[...]
4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core
.active_extensions = (__u8)2,
[...]
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)
.active_extensions = (__u8)2,
In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption.
This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.(CVE-2025-37959)
In the Linux kernel, the following vulnerability has been resolved:
memblock: Accept allocated memory before use in memblock_double_array()
When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest:
RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b
Mitigate this by calling accept_memory() on the memory range returned before the slab is available.
Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.(CVE-2025-37960)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix uninit-value for saddr in do_output_route4
syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr.
[1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---(CVE-2025-37961)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: leds: fix memory leak
A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code.
The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound.
This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer.
Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.(CVE-2025-37989)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()
The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions.
Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized.
Improve the error message to report more detailed error information.(CVE-2025-37990)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add missing rcu read protection for procfs content
When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF).
As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.(CVE-2025-38003)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking for bcm_op runtime updates
The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero.
Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.(CVE-2025-38004)
In the Linux kernel, the following vulnerability has been resolved:
phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking
The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as:
[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270
The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count.
To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually.
With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles.
The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices
The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices:
# ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP
(Note that the neighbor is not marked with 'offload')
When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one:
# devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP
If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted:
# ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1
Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Disable MACsec offload for uplink representor profile
MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features.
If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set.
Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().
Kernel log:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: <TASK> ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 _syssendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen ---truncated---(CVE-2025-38020)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem
Call Trace:
__dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] _syssendmsg+0xa95/0xc70 net/socket.c:2566 _sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes.
The root cause is: the function ib_device_rename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time.
The solution is to add the lock protection when this name is accessed in the function kobject_uevent().(CVE-2025-38022)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur.
The solution is to let rxe_cleanup do all the work.(CVE-2025-38024)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled
When attempting to enable MQPRIO while HTB offload is already
configured, the driver currently returns -EINVAL and triggers a
WARN_ON, leading to an unnecessary call trace.
Update the code to handle this case more gracefully by returning
-EOPNOTSUPP instead, while also providing a helpful user message.(CVE-2025-38039)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn
The user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can run on multiple platforms having different DMA architectures. On some platforms there can be one FDQ for all flows in the RX channel while for others there is a separate FDQ for each flow in the RX channel.
So far we have been relying on the skip_fdq argument of k3_udma_glue_reset_rx_chn().
Instead of relying on the user to provide this information, infer it based on DMA architecture during k3_udma_glue_request_rx_chn() and save it in an internal flag 'single_fdq'. Use that flag at k3_udma_glue_reset_rx_chn() to deicide if the FDQ needs to be cleared for every flow or just for flow 0.
Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.
> ip link set eth1 down > ip link set eth0 down > ethtool -L eth0 rx 8 > ip link set eth0 up > modprobe -r ti_am65_cpsw_nuss
[ 103.045726] ------------[ cut here ]------------ [ 103.050505] k3_knav_desc_pool size 512000 != avail 64000 [ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool] [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT) [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.154709] sp : ffff8000826ebbc0 [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [ 103.229274] Call trace: [ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P) [ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss] [ 103.244942] devm_action_release+0x14/0x20 [ 103.249040] release_nodes+0x3c/0x68 [ 103.252610] devres_release_all+0x8c/0xdc [ 103.256614] device_unbind_cleanup+0x18/0x60 [ 103.260876] device_release_driver_internal+0xf8/0x178 [ 103.266004] driver_detach+0x50/0x9c [ 103.269571] bus_remove_driver+0x6c/0xbc [ 103.273485] driver_unregister+0x30/0x60 [ 103.277401] platform_driver_unregister+0x14/0x20 [ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss] [ 103.288620] __arm64_sys_delete_module+0x17c/0x25c [ 103.293404] invoke_syscall+0x44/0x100 [ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0 [ 103.301845] do_el0_svc+0x1c/0x28 [ 103.305155] el0_svc+0x28/0x98 ---truncated---(CVE-2025-38042)
In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: set device_caps for 417
The video_device for the MPEG encoder did not set device_caps.
Add this, otherwise the video device can't be registered (you get a WARN_ON instead).
Not seen before since currently 417 support is disabled, but I found this while experimenting with it.(CVE-2025-38044)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: fix skb leaks
A few error paths are missing a kfree_skb.(CVE-2025-38057)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: prevent BUG_ON by blocking retries on failed device resumes
A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object.
Reproduce steps:
- create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.
cat <<EOF >> cmeta.xml <superblock uuid="" block_size="128" nr_cache_blocks="512" \ policy="smq" hint_width="4"> <mappings> <mapping cache_block="0" origin_block="0" dirty="false"/> </mappings> </superblock> EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta
- wipe the second array block of the mapping array to simulate data degradations.
mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock
- try bringing up the cache device. The resume is expected to fail due to the broken array block.
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache
- try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.
dmsetup resume cache
Kernel logs:
(snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570
Fix by disallowing resume operations for devices that failed the initial attempt.(CVE-2025-38066)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed.
If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected.
Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.(CVE-2025-38085)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix use-after-free in taprio_dev_notifier
Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free.
Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.
The reference chain is: xfrm_state -> enacp_sk -> netns
Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.
This patch results in a small (~2% in my tests) performance regression.
A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.(CVE-2025-38097)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: Fix use-after-free in page_pool_recycle_in_ring
syzbot reported a uaf in page_pool_recycle_in_ring:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943
CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]
root cause is:
page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free
spin_unlock(&r->producer_lock); //pool->ring uaf read
recycle_stat_inc(pool, ring);
page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled.
recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.(CVE-2025-38129)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.
Race conditions: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''
The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''
Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread and close() thread.
The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix panic when calling skb_linearize
The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000
Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] <TASK> [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfxlockrelease.isra.0+0x10/0x10 [ 657.473826] pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 '''
The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed.
The "--rx-strp 100000" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.
To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.
''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress__ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply___↑ skb_linearize '''
Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior.(CVE-2025-38165)
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix ktls panic with sockmap
[ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] <TASK> [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ......
After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data().
If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); '''
The changes in this commit are based on the following considerations:
-
When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic.
-
We can not calculate the correct number of bytes to revert msg_iter.
Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement.
However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed.
So it doesn't seem as simple as just reverting through an offset of msg_iter.
- For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached.
Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; '''
So it's ok to just return 'copied' without error when a "cork" situation occurs.(CVE-2025-38166)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: make hfsc_qlen_notify() idempotent
hfsc_qlen_notify() is not idempotent either and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life:
-
update_vf() decreases cl->cl_nactive, so we can check whether it is non-zero before calling it.
-
eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush
In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated.
However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way.
Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.(CVE-2025-38351)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks
After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.(CVE-2025-38412)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: do not bypass hid_hw_raw_request
hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)
In the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net->xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net->collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)
In the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)
In the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Prevent VMA split of buffer mappings
The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct.
Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks.
As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented.
Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL.
That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.(CVE-2025-38563)
In the Linux kernel, the following vulnerability has been resolved:
benet: fix BUG when creating VFs
benet crashes as soon as SRIOV VFs are created:
kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: <TASK> __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0
be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh. Fix it by freeing only after the lock has been released.(CVE-2025-38569)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix double destruction of rsv_qp
rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init().
list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18(CVE-2025-38582)
In the Linux kernel, the following vulnerability has been resolved:
vmci: Prevent the dispatching of uninitialized payloads
The reproducer executes the host's unlocked_ioctl call in two different tasks. When init_context fails, the struct vmci_event_ctx is not fully initialized when executing vmci_datagram_dispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space.
Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization.(CVE-2025-38611)
In the Linux kernel, the following vulnerability has been resolved:
pinmux: fix race causing mux_owner NULL with active mux_usecount
commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer.
The issue occurs due to the following interleaving:
cpu0 (process A) cpu1 (process B)
pin_request() { pin_free() {
mutex_lock()
desc->mux_usecount--; //becomes 0
..
mutex_unlock()
mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux)
mutex_lock(desc->mux)
desc->mux_owner = NULL;
mutex_unlock(desc->mux)
This sequence leads to a state where the pin appears to be in use
(mux_usecount == 1) but has no owner (mux_owner == NULL), which can
cause NULL pointer on next pin_request on the same pin.
Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned.(CVE-2025-38632)
In the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro's suggestion, it was fixed in the same manner.(CVE-2025-38653)
In the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"perf-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.111.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-108.0.0.111.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"perf-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-108.0.0.111.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.111.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-108.0.0.111.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: Destroy device along with udp socket\u0026apos;s netns dismantle.\n\ngtp_newlink() links the device to a list in dev_net(dev) instead of\nsrc_net, where a udp tunnel socket is created.\n\nEven when src_net is removed, the device stays alive on dev_net(dev).\nThen, removing src_net triggers the splat below. [0]\n\nIn this example, gtp0 is created in ns2, and the udp socket is created\nin ns1.\n\n ip netns add ns1\n ip netns add ns2\n ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn\n ip netns del ns1\n\nLet\u0026apos;s link the device to the socket\u0026apos;s netns instead.\n\nNow, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove\nall gtp devices in the netns.\n\n[0]:\nref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at\n sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)\n inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)\n __sock_create (net/socket.c:1558)\n udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)\n gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)\n gtp_create_sockets (drivers/net/gtp.c:1447)\n gtp_newlink (drivers/net/gtp.c:1507)\n rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)\n netlink_rcv_skb (net/netlink/af_netlink.c:2542)\n netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)\n netlink_sendmsg (net/netlink/af_netlink.c:1891)\n ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)\n ___sys_sendmsg (net/socket.c:2639)\n __sys_sendmsg (net/socket.c:2669)\n do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n\nWARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\nModules linked in:\nCPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: netns cleanup_net\nRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)\nCode: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 \u0026lt;0f\u0026gt; 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89\nRSP: 0018:ff11000009a07b60 EFLAGS: 00010286\nRAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c\nRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae\nR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0\nR13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn (kernel/panic.c:748)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:285)\n ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)\n ? kfree (mm/slub.c:4613 mm/slub.c:4761)\n net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)\n cleanup_net (net/core/net_namespace.c:664 (discriminator 3))\n process_one_work (kernel/workqueue.c:3229)\n worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391\n---truncated---(CVE-2025-21678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix possible crash when setting up bsg fails\n\nIf bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value.\nConsequently, in mpi3mr_bsg_exit(), the condition \u0026quot;if(!mrioc-\u0026gt;bsg_queue)\u0026quot;\nwill not be satisfied, preventing execution from entering\nbsg_remove_queue(), which could lead to the following crash:\n\nBUG: kernel NULL pointer dereference, address: 000000000000041c\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]\n mpi3mr_remove+0x6f/0x340 [mpi3mr]\n pci_device_remove+0x3f/0xb0\n device_release_driver_internal+0x19d/0x220\n unbind_store+0xa4/0xb0\n kernfs_fop_write_iter+0x11f/0x200\n vfs_write+0x1fc/0x3e0\n ksys_write+0x67/0xe0\n do_syscall_64+0x38/0x80\n entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: drop secpath at the same time as we currently drop dst\n\nXiumei reported hitting the WARN in xfrm6_tunnel_net_exit while\nrunning tests that boil down to:\n - create a pair of netns\n - run a basic TCP test over ipcomp6\n - delete the pair of netns\n\nThe xfrm_state found on spi_byaddr was not deleted at the time we\ndelete the netns, because we still have a reference on it. This\nlingering reference comes from a secpath (which holds a ref on the\nxfrm_state), which is still attached to an skb. This skb is not\nleaked, it ends up on sk_receive_queue and then gets defer-free\u0026apos;d by\nskb_attempt_defer_free.\n\nThe problem happens when we defer freeing an skb (push it on one CPU\u0026apos;s\ndefer_list), and don\u0026apos;t flush that list before the netns is deleted. In\nthat case, we still have a reference on the xfrm_state that we don\u0026apos;t\nexpect at this point.\n\nWe already drop the skb\u0026apos;s dst in the TCP receive path when it\u0026apos;s no\nlonger needed, so let\u0026apos;s also drop the secpath. At this point,\ntcp_filter has already called into the LSM hooks that may require the\nsecpath, so it should not be needed anymore. However, in some of those\nplaces, the MPTCP extension has just been attached to the skb, so we\ncannot simply drop all extensions.(CVE-2025-21864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix type confusion via race condition when using ipc_msg_send_request\n\nreq-\u0026gt;handle is allocated using ksmbd_acquire_id(\u0026amp;ipc_ida), based on\nida_alloc. req-\u0026gt;handle from ksmbd_ipc_login_request and\nFSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion\nbetween messages, resulting in access to unexpected parts of memory after\nan incorrect delivery. ksmbd check type of ipc response but missing add\ncontinue to check next ipc reponse.(CVE-2025-21947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent connection release during oplock break notification\n\nksmbd_work could be freed when after connection release.\nIncrement r_count of ksmbd_conn to indicate that requests\nare not finished yet and to not release the connection.(CVE-2025-21955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix error code in chan_alloc_skb_cb()\n\nThe chan_alloc_skb_cb() function is supposed to return error pointers on\nerror. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: socket: Lookup orig tuple for IPv6 SNAT\n\nnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to\nrestore the original 5-tuple in case of SNAT, to be able to find the\nright socket (if any). Then socket_match() can correctly check whether\nthe socket was transparent.\n\nHowever, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this\nconntrack lookup, making xt_socket fail to match on the socket when the\npacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.\n\nIPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as\npods\u0026apos; addresses are in the fd00::/8 ULA subnet and need to be replaced\nwith the node\u0026apos;s external address. Cilium leverages Envoy to enforce L7\npolicies, and Envoy uses transparent sockets. Cilium inserts an iptables\nprerouting rule that matches on `-m socket --transparent` and redirects\nthe packets to localhost, but it fails to match SNATed IPv6 packets due\nto that missing conntrack lookup.(CVE-2025-22021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_tunnel: fix geneve_opt type confusion addition\n\nWhen handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the\nparsing logic should place every geneve_opt structure one by one\ncompactly. Hence, when deciding the next geneve_opt position, the\npointer addition should be in units of char *.\n\nHowever, the current implementation erroneously does type conversion\nbefore the addition, which will lead to heap out-of-bounds write.\n\n[ 6.989857] ==================================================================\n[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70\n[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178\n[ 6.991162]\n[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1\n[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[ 6.992281] Call Trace:\n[ 6.992423] \u0026lt;TASK\u0026gt;\n[ 6.992586] dump_stack_lvl+0x44/0x5c\n[ 6.992801] print_report+0x184/0x4be\n[ 6.993790] kasan_report+0xc5/0x100\n[ 6.994252] kasan_check_range+0xf3/0x1a0\n[ 6.994486] memcpy+0x38/0x60\n[ 6.994692] nft_tunnel_obj_init+0x977/0xa70\n[ 6.995677] nft_obj_init+0x10c/0x1b0\n[ 6.995891] nf_tables_newobj+0x585/0x950\n[ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020\n[ 6.998997] nfnetlink_rcv+0x1df/0x220\n[ 6.999537] netlink_unicast+0x395/0x530\n[ 7.000771] netlink_sendmsg+0x3d0/0x6d0\n[ 7.001462] __sock_sendmsg+0x99/0xa0\n[ 7.001707] ____sys_sendmsg+0x409/0x450\n[ 7.002391] ___sys_sendmsg+0xfd/0x170\n[ 7.003145] __sys_sendmsg+0xea/0x170\n[ 7.004359] do_syscall_64+0x5e/0x90\n[ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 7.006127] RIP: 0033:0x7ec756d4e407\n[ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407\n[ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003\n[ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000\n[ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\n[ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8\n\nFix this bug with correct pointer addition and conversion in parse\nand dump code.(CVE-2025-22056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: decrease cached dst counters in dst_release\n\nUpstream fix ac888d58869b (\u0026quot;net: do not delay dst_entries_add() in\ndst_release()\u0026quot;) moved decrementing the dst count from dst_destroy to\ndst_release to avoid accessing already freed data in case of netns\ndismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels\nare used, this fix is incomplete as the same issue will be seen for\ncached dsts:\n\n Unable to handle kernel paging request at virtual address ffff5aabf6b5c000\n Call trace:\n percpu_counter_add_batch+0x3c/0x160 (P)\n dst_release+0xec/0x108\n dst_cache_destroy+0x68/0xd8\n dst_destroy+0x13c/0x168\n dst_destroy_rcu+0x1c/0xb0\n rcu_do_batch+0x18c/0x7d0\n rcu_core+0x174/0x378\n rcu_core_si+0x18/0x30\n\nFix this by invalidating the cache, and thus decrementing cached dst\ncounters, in dst_release too.(CVE-2025-22057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets\n\nWhen calling netlbl_conn_setattr(), addr-\u0026gt;sa_family is used\nto determine the function behavior. If sk is an IPv4 socket,\nbut the connect function is called with an IPv6 address,\nthe function calipso_sock_setattr() is triggered.\nInside this function, the following code is executed:\n\nsk_fullsock(__sk) ? inet_sk(__sk)-\u0026gt;pinet6 : NULL;\n\nSince sk is an IPv4 socket, pinet6 is NULL, leading to a\nnull pointer dereference.\n\nThis patch fixes the issue by checking if inet6_sk(sk)\nreturns a NULL pointer before accessing pinet6.(CVE-2025-22063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don\u0026apos;t unregister hook when table is dormant\n\nWhen nf_tables_updchain encounters an error, hook registration needs to\nbe rolled back.\n\nThis should only be done if the hook has been registered, which won\u0026apos;t\nhappen when the table is flagged as dormant (inactive).\n\nJust move the assignment into the registration block.(CVE-2025-22064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow\n\nWhen cur_qp isn\u0026apos;t NULL, in order to avoid fetching the QP from\nthe radix tree again we check if the next cqe QP is identical to\nthe one we already have.\n\nThe bug however is that we are checking if the QP is identical by\nchecking the QP number inside the CQE against the QP number inside the\nmlx5_ib_qp, but that\u0026apos;s wrong since the QP number from the CQE is from\nFW so it should be matched against mlx5_core_qp which is our FW QP\nnumber.\n\nOtherwise we could use the wrong QP when handling a CQE which could\ncause the kernel trace below.\n\nThis issue is mainly noticeable over QPs 0 \u0026amp; 1, since for now they are\nthe only QPs in our driver whereas the QP number inside mlx5_ib_qp\ndoesn\u0026apos;t match the QP number inside mlx5_core_qp.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\n RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 \u0026lt;0f\u0026gt; b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21\n RSP: 0018:ffff88810511bd60 EFLAGS: 00010046\n RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a\n RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10\n R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000\n R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0\n FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n __ib_process_cq+0x5a/0x150 [ib_core]\n ib_cq_poll_work+0x31/0x90 [ib_core]\n process_one_work+0x169/0x320\n worker_thread+0x288/0x3a0\n ? work_busy+0xb0/0xb0\n kthread+0xd7/0x1f0\n ? kthreads_online_cpu+0x130/0x130\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork+0x2d/0x50\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;(CVE-2025-22086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Don\u0026apos;t expose hw_counters outside of init net namespace\n\nCommit 467f432a521a (\u0026quot;RDMA/core: Split port and device counter sysfs\nattributes\u0026quot;) accidentally almost exposed hw counters to non-init net\nnamespaces. It didn\u0026apos;t expose them fully, as an attempt to read any of\nthose counters leads to a crash like this one:\n\n[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028\n[42021.814463] #PF: supervisor read access in kernel mode\n[42021.819549] #PF: error_code(0x0000) - not-present page\n[42021.824636] PGD 0 P4D 0\n[42021.827145] Oops: 0000 [#1] SMP PTI\n[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX\n[42021.841697] Hardware name: XXX\n[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff \u0026lt;48\u0026gt; 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48\n[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287\n[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000\n[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0\n[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000\n[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530\n[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000\n[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000\n[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0\n[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[42021.949324] Call Trace:\n[42021.951756] \u0026lt;TASK\u0026gt;\n[42021.953842] [\u0026lt;ffffffff86c58674\u0026gt;] ? show_regs+0x64/0x70\n[42021.959030] [\u0026lt;ffffffff86c58468\u0026gt;] ? __die+0x78/0xc0\n[42021.963874] [\u0026lt;ffffffff86c9ef75\u0026gt;] ? page_fault_oops+0x2b5/0x3b0\n[42021.969749] [\u0026lt;ffffffff87674b92\u0026gt;] ? exc_page_fault+0x1a2/0x3c0\n[42021.975549] [\u0026lt;ffffffff87801326\u0026gt;] ? asm_exc_page_fault+0x26/0x30\n[42021.981517] [\u0026lt;ffffffffc0775680\u0026gt;] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]\n[42021.988482] [\u0026lt;ffffffffc077564e\u0026gt;] ? hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.995438] [\u0026lt;ffffffff86ac7f8e\u0026gt;] dev_attr_show+0x1e/0x50\n[42022.000803] [\u0026lt;ffffffff86a3eeb1\u0026gt;] sysfs_kf_seq_show+0x81/0xe0\n[42022.006508] [\u0026lt;ffffffff86a11134\u0026gt;] seq_read_iter+0xf4/0x410\n[42022.011954] [\u0026lt;ffffffff869f4b2e\u0026gt;] vfs_read+0x16e/0x2f0\n[42022.017058] [\u0026lt;ffffffff869f50ee\u0026gt;] ksys_read+0x6e/0xe0\n[42022.022073] [\u0026lt;ffffffff8766f1ca\u0026gt;] do_syscall_64+0x6a/0xa0\n[42022.027441] [\u0026lt;ffffffff8780013b\u0026gt;] entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe problem can be reproduced using the following steps:\n ip netns add foo\n ip netns exec foo bash\n cat /sys/class/infiniband/mlx4_0/hw_counters/*\n\nThe panic occurs because of casting the device pointer into an\nib_device pointer using container_of() in hw_stat_device_show() is\nwrong and leads to a memory corruption.\n\nHowever the real problem is that hw counters should never been exposed\noutside of the non-init net namespace.\n\nFix this by saving the index of the corresponding attribute group\n(it might be 1 or 2 depending on the presence of driver-specific\nattributes) and zeroing the pointer to hw_counters group for compat\ndevices during the initialization.\n\nWith this fix applied hw_counters are not available in a non-init\nnet namespace:\n find /sys/class/infiniband/mlx4_0/ -name hw_counters\n /sys/class/infiniband/mlx4_0/ports/1/hw_counters\n /sys/class/infiniband/mlx4_0/ports/2/hw_counters\n /sys/class/infiniband/mlx4_0/hw_counters\n\n ip netns add foo\n ip netns exec foo bash\n find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: unregister xdp rxq info in the reset path\n\nvmxnet3 does not unregister xdp rxq info in the\nvmxnet3_reset_work() code path as vmxnet3_rq_destroy()\nis not invoked in this code path. So, we get below message with a\nbacktrace.\n\nMissing unregister, handled but fix driver\nWARNING: CPU:48 PID: 500 at net/core/xdp.c:182\n__xdp_rxq_info_reg+0x93/0xf0\n\nThis patch fixes the problem by moving the unregister\ncode of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ppp: Add bound checking for skb data on ppp_sync_txmung\n\nEnsure we have enough data in linear buffer from skb before accessing\ninitial bytes. This prevents potential out-of-bounds accesses\nwhen processing short packets.\n\nWhen ppp_sync_txmung receives an incoming package with an empty\npayload:\n(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)\n$18 = {\n\ttype = 0x1,\n\tver = 0x1,\n\tcode = 0x0,\n\tsid = 0x2,\n length = 0x0,\n\ttag = 0xffff8880371cdb96\n}\n\nfrom the skb struct (trimmed)\n tail = 0x16,\n end = 0x140,\n head = 0xffff88803346f400 \u0026quot;4\u0026quot;,\n data = 0xffff88803346f416 \u0026quot;:\\377\u0026quot;,\n truesize = 0x380,\n len = 0x0,\n data_len = 0x0,\n mac_len = 0xe,\n hdr_len = 0x0,\n\nit is not safe to access data[2].\n\n[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: move the limit validation\n\nIt is not sufficient to directly validate the limit on the data that\nthe user passes as it can be updated based on how the other parameters\nare changed.\n\nMove the check at the end of the configuration update process to also\ncatch scenarios where the limit is indirectly updated, for example\nwith the following configurations:\n\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1\n\nThis fixes the following syzkaller reported crash:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6\nindex 65535 is out of range for type \u0026apos;struct sfq_head[128]\u0026apos;\nCPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429\n sfq_link net/sched/sch_sfq.c:203 [inline]\n sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231\n sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493\n sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311\n netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]\n dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix workqueue crash in cma_netevent_work_handler\n\nstruct rdma_cm_id has member \u0026quot;struct work_struct net_work\u0026quot;\nthat is reused for enqueuing cma_netevent_work_handler()s\nonto cma_wq.\n\nBelow crash[1] can occur if more than one call to\ncma_netevent_callback() occurs in quick succession,\nwhich further enqueues cma_netevent_work_handler()s for the\nsame rdma_cm_id, overwriting any previously queued work-item(s)\nthat was just scheduled to run i.e. there is no guarantee\nthe queued work item may run between two successive calls\nto cma_netevent_callback() and the 2nd INIT_WORK would overwrite\nthe 1st work item (for the same rdma_cm_id), despite grabbing\nid_table_lock during enqueue.\n\nAlso drgn analysis [2] indicates the work item was likely overwritten.\n\nFix this by moving the INIT_WORK() to __rdma_create_id(),\nso that it doesn\u0026apos;t race with any existing queue_work() or\nits worker thread.\n\n[1] Trimmed crash stack:\n=============================================\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nkworker/u256:6 ... 6.12.0-0...\nWorkqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)\nRIP: 0010:process_one_work+0xba/0x31a\nCall Trace:\n worker_thread+0x266/0x3a0\n kthread+0xcf/0x100\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n=============================================\n\n[2] drgn crash analysis:\n\n\u0026gt;\u0026gt;\u0026gt; trace = prog.crashed_thread().stack_trace()\n\u0026gt;\u0026gt;\u0026gt; trace\n(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)\n(1) __crash_kexec (kernel/crash_core.c:122:4)\n(2) panic (kernel/panic.c:399:3)\n(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)\n...\n(8) process_one_work (kernel/workqueue.c:3168:2)\n(9) process_scheduled_works (kernel/workqueue.c:3310:3)\n(10) worker_thread (kernel/workqueue.c:3391:4)\n(11) kthread (kernel/kthread.c:389:9)\n\nLine workqueue.c:3168 for this kernel version is in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;work\u0026quot;]\n*(struct work_struct *)0xffff92577d0a21d8 = {\n\t.data = (atomic_long_t){\n\t\t.counter = (s64)536870912, \u0026lt;=== Note\n\t},\n\t.entry = (struct list_head){\n\t\t.next = (struct list_head *)0xffff924d075924c0,\n\t\t.prev = (struct list_head *)0xffff924d075924c0,\n\t},\n\t.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,\n}\n\nSuspicion is that pwq is NULL:\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;pwq\u0026quot;]\n(struct pool_workqueue *)\u0026lt;absent\u0026gt;\n\nIn process_one_work(), pwq is assigned from:\nstruct pool_workqueue *pwq = get_work_pwq(work);\n\nand get_work_pwq() is:\nstatic struct pool_workqueue *get_work_pwq(struct work_struct *work)\n{\n \tunsigned long data = atomic_long_read(\u0026amp;work-\u0026gt;data);\n\n \tif (data \u0026amp; WORK_STRUCT_PWQ)\n \t\treturn work_struct_pwq(data);\n \telse\n \t\treturn NULL;\n}\n\nWORK_STRUCT_PWQ is 0x4:\n\u0026gt;\u0026gt;\u0026gt; print(repr(prog[\u0026apos;WORK_STRUCT_PWQ\u0026apos;]))\nObject(prog, \u0026apos;enum work_flags\u0026apos;, value=4)\n\nBut work-\u0026gt;data is 536870912 which is 0x20000000.\nSo, get_work_pwq() returns NULL and we crash in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n=============================================(CVE-2025-37772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt\u0026apos;s not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Purge vif txq in ieee80211_do_stop()\n\nAfter ieee80211_do_stop() SKB from vif\u0026apos;s txq could still be processed.\nIndeed another concurrent vif schedule_and_wake_txq call could cause\nthose packets to be dequeued (see ieee80211_handle_wake_tx_queue())\nwithout checking the sdata current state.\n\nBecause vif.drv_priv is now cleared in this function, this could lead to\ndriver crash.\n\nFor example in ath12k, ahvif is store in vif.drv_priv. Thus if\nath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif-\u0026gt;ah can be\nNULL, leading the ath12k_warn(ahvif-\u0026gt;ah,...) call in this function to\ntrigger the NULL deref below.\n\n Unable to handle kernel paging request at virtual address dfffffc000000001\n KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n batman_adv: bat0: Interface deactivated: brbh1337\n Mem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n [dfffffc000000001] address between user and kernel address ranges\n Internal error: Oops: 0000000096000004 [#1] SMP\n CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114\n Hardware name: HW (DT)\n pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]\n lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]\n sp : ffffffc086ace450\n x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4\n x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e\n x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0\n x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958\n x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8\n x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03\n x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40\n x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0\n x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001\n x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008\n Call trace:\n ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)\n ieee80211_handle_wake_tx_queue+0x16c/0x260\n ieee80211_queue_skb+0xeec/0x1d20\n ieee80211_tx+0x200/0x2c8\n ieee80211_xmit+0x22c/0x338\n __ieee80211_subif_start_xmit+0x7e8/0xc60\n ieee80211_subif_start_xmit+0xc4/0xee0\n __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0\n ieee80211_subif_start_xmit_8023+0x124/0x488\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n br_dev_queue_push_xmit+0x120/0x4a8\n __br_forward+0xe4/0x2b0\n deliver_clone+0x5c/0xd0\n br_flood+0x398/0x580\n br_dev_xmit+0x454/0x9f8\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n ip6_finish_output2+0xc28/0x1b60\n __ip6_finish_output+0x38c/0x638\n ip6_output+0x1b4/0x338\n ip6_local_out+0x7c/0xa8\n ip6_send_skb+0x7c/0x1b0\n ip6_push_pending_frames+0x94/0xd0\n rawv6_sendmsg+0x1a98/0x2898\n inet_sendmsg+0x94/0xe0\n __sys_sendto+0x1e4/0x308\n __arm64_sys_sendto+0xc4/0x140\n do_el0_svc+0x110/0x280\n el0_svc+0x20/0x60\n el0t_64_sync_handler+0x104/0x138\n el0t_64_sync+0x154/0x158\n\nTo avoid that, empty vif\u0026apos;s txq at ieee80211_do_stop() so no packet could\nbe dequeued after ieee80211_do_stop() (new packets cannot be queued\nbecause SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy-\u0026gt;cpus mask. scpi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.(CVE-2025-37829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don\u0026apos;t try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n page isn\u0026apos;t locked, inject memory failure for the page. \n me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n but fails. Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn\u0026apos;t in lru list.(CVE-2025-37834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: avoid infinite loop to schedule delayed worker\n\nWe noticed the kworker in page_pool_release_retry() was waken\nup repeatedly and infinitely in production because of the\nbuggy driver causing the inflight less than 0 and warning\nus in page_pool_inflight()[1].\n\nSince the inflight value goes negative, it means we should\nnot expect the whole page_pool to get back to work normally.\n\nThis patch mitigates the adverse effect by not rescheduling\nthe kworker when detecting the inflight negative in\npage_pool_release_retry().\n\n[1]\n[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------\n[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages\n...\n[Mon Feb 10 20:36:11 2025] Call Trace:\n[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70\n[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370\n[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0\n[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140\n[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370\n[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40\n[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40\n[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---\nNote: before this patch, the above calltrace would flood the\ndmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigc: fix PTM cycle trigger logic\n\nWriting to clear the PTM status \u0026apos;valid\u0026apos; bit while the PTM cycle is\ntriggered results in unreliable PTM operation. To fix this, clear the\nPTM \u0026apos;trigger\u0026apos; and status after each PTM transaction.\n\nThe issue can be reproduced with the following:\n\n$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m\n\nNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way to\nquickly reproduce the issue.\n\nPHC2SYS exits with:\n\n\u0026quot;ioctl PTP_OFFSET_PRECISE: Connection timed out\u0026quot; when the PTM transaction\n fails\n\nThis patch also fixes a hang in igc_probe() when loading the igc\ndriver in the kdump kernel on systems supporting PTM.\n\nThe igc driver running in the base kernel enables PTM trigger in\nigc_probe(). Therefore the driver is always in PTM trigger mode,\nexcept in brief periods when manually triggering a PTM cycle.\n\nWhen a crash occurs, the NIC is reset while PTM trigger is enabled.\nDue to a hardware problem, the NIC is subsequently in a bad busmaster\nstate and doesn\u0026apos;t handle register reads/writes. When running\nigc_probe() in the kdump kernel, the first register access to a NIC\nregister hangs driver probing and ultimately breaks kdump.\n\nWith this patch, igc has PTM trigger disabled most of the time,\nand the trigger is only enabled for very brief (10 - 100 us) periods\nwhen manually triggering a PTM cycle. Chances that a crash occurs\nduring a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/net: fix improper handling of bogus negative read/write replies\n\nIn p9_client_write() and p9_client_read_once(), if the server\nincorrectly replies with success but a negative write/read count then we\nwould consider written (negative) \u0026lt;= rsize (positive) because both\nvariables were signed.\n\nMake variables unsigned to avoid this problem.\n\nThe reproducer linked below now fails with the following error instead\nof a null pointer deref:\n9pnet: bogus RWRITE count (4294967295 \u0026gt; 3)(CVE-2025-37879)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reset IRTE to host control if *new* route isn\u0026apos;t postable\n\nRestore an IRTE back to host control (remapped or posted MSI mode) if the\n*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of\nthe GSI routing type. Updating the IRTE if and only if the new GSI is an\nMSI results in KVM leaving an IRTE posting to a vCPU.\n\nThe dangling IRTE can result in interrupts being incorrectly delivered to\nthe guest, and in the worst case scenario can result in use-after-free,\ne.g. if the VM is torn down, but the underlying host IRQ isn\u0026apos;t freed.(CVE-2025-37885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: Fix memleak issue when GSO enabled\n\nAlways map the `skb` to the LS descriptor. Previously skb was\nmapped to EXT descriptor when the number of fragments is zero with\nGSO enabled. Mapping the skb to EXT descriptor prevents it from\nbeing freed, leading to a memory leak(CVE-2025-37909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix out-of-bound memcpy() during ethtool -w\n\nWhen retrieving the FW coredump using ethtool, it can sometimes cause\nmemory corruption:\n\nBUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nCorrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):\n__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nethtool_get_dump_data+0xdc/0x1a0\n__dev_ethtool+0xa1e/0x1af0\ndev_ethtool+0xa8/0x170\ndev_ioctl+0x1b5/0x580\nsock_do_ioctl+0xab/0xf0\nsock_ioctl+0x1ce/0x2e0\n__x64_sys_ioctl+0x87/0xc0\ndo_syscall_64+0x5c/0xf0\nentry_SYSCALL_64_after_hwframe+0x78/0x80\n\n...\n\nThis happens when copying the coredump segment list in\nbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.\nThe info-\u0026gt;dest_buf buffer is allocated based on the number of coredump\nsegments returned by the FW. The segment list is then DMA\u0026apos;ed by\nthe FW and the length of the DMA is returned by FW. The driver then\ncopies this DMA\u0026apos;ed segment list to info-\u0026gt;dest_buf.\n\nIn some cases, this DMA length may exceed the info-\u0026gt;dest_buf length\nand cause the above BUG condition. Fix it by capping the copy\nlength to not exceed the length of info-\u0026gt;dest_buf. The extra\nDMA data contains no useful information.\n\nThis code path is shared for the HWRM_DBG_COREDUMP_LIST and the\nHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different\nfor these 2 FW commands. To simplify the logic, we need to move\nthe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE\nup, so that the new check to cap the copy length will work for both\ncommands.(CVE-2025-37911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()\n\nAs mentioned in the commit baeb705fd6a7 (\u0026quot;ice: always check VF VSI\npointer values\u0026quot;), we need to perform a null pointer check on the return\nvalue of ice_get_vf_vsi() before using it.(CVE-2025-37912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: make htb_qlen_notify() idempotent\n\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\n\nLet\u0026apos;s make it idempotent to ease qdisc_tree_reduce_backlog() callers\u0026apos;\nlife.(CVE-2025-37932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY\n\nDSA has 2 kinds of drivers:\n\n1. Those who call dsa_switch_suspend() and dsa_switch_resume() from\n their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz\n2. Those who don\u0026apos;t: all others. The above methods should be optional.\n\nFor type 1, dsa_switch_suspend() calls dsa_user_suspend() -\u0026gt; phylink_stop(),\nand dsa_switch_resume() calls dsa_user_resume() -\u0026gt; phylink_start().\nThese seem good candidates for setting mac_managed_pm = true because\nthat is essentially its definition [1], but that does not seem to be the\nbiggest problem for now, and is not what this change focuses on.\n\nTalking strictly about the 2nd category of DSA drivers here (which\ndo not have MAC managed PM, meaning that for their attached PHYs,\nmdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),\nI have noticed that the following warning from mdio_bus_phy_resume() is\ntriggered:\n\n\tWARN_ON(phydev-\u0026gt;state != PHY_HALTED \u0026amp;\u0026amp; phydev-\u0026gt;state != PHY_READY \u0026amp;\u0026amp;\n\t\tphydev-\u0026gt;state != PHY_UP);\n\nbecause the PHY state machine is running.\n\nIt\u0026apos;s running as a result of a previous dsa_user_open() -\u0026gt; ... -\u0026gt;\nphylink_start() -\u0026gt; phy_start() having been initiated by the user.\n\nThe previous mdio_bus_phy_suspend() was supposed to have called\nphy_stop_machine(), but it didn\u0026apos;t. So this is why the PHY is in state\nPHY_NOLINK by the time mdio_bus_phy_resume() runs.\n\nmdio_bus_phy_suspend() did not call phy_stop_machine() because for\nphylink, the phydev-\u0026gt;adjust_link function pointer is NULL. This seems a\ntechnicality introduced by commit fddd91016d16 (\u0026quot;phylib: fix PAL state\nmachine restart on resume\u0026quot;). That commit was written before phylink\nexisted, and was intended to avoid crashing with consumer drivers which\ndon\u0026apos;t use the PHY state machine - phylink always does, when using a PHY.\nBut phylink itself has historically not been developed with\nsuspend/resume in mind, and apparently not tested too much in that\nscenario, allowing this bug to exist unnoticed for so long. Plus, prior\nto the WARN_ON(), it would have likely been invisible.\n\nThis issue is not in fact restricted to type 2 DSA drivers (according to\nthe above ad-hoc classification), but can be extrapolated to any MAC\ndriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where\nthe issue was reported. Assuming mac_managed_pm is set correctly, a\nquick search indicates the following other drivers might be affected:\n\n$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm\ndrivers/net/ethernet/atheros/ag71xx.c\ndrivers/net/ethernet/microchip/sparx5/sparx5_main.c\ndrivers/net/ethernet/microchip/lan966x/lan966x_main.c\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c\ndrivers/net/ethernet/freescale/fs_enet/fs_enet-main.c\ndrivers/net/ethernet/freescale/dpaa/dpaa_eth.c\ndrivers/net/ethernet/freescale/ucc_geth.c\ndrivers/net/ethernet/freescale/enetc/enetc_pf_common.c\ndrivers/net/ethernet/marvell/mvpp2/mvpp2_main.c\ndrivers/net/ethernet/marvell/mvneta.c\ndrivers/net/ethernet/marvell/prestera/prestera_main.c\ndrivers/net/ethernet/mediatek/mtk_eth_soc.c\ndrivers/net/ethernet/altera/altera_tse_main.c\ndrivers/net/ethernet/wangxun/txgbe/txgbe_phy.c\ndrivers/net/ethernet/meta/fbnic/fbnic_phylink.c\ndrivers/net/ethernet/tehuti/tn40_phy.c\ndrivers/net/ethernet/mscc/ocelot_net.c\n\nMake the existing conditions dependent on the PHY device having a\nphydev-\u0026gt;phy_link_change() implementation equal to the default\nphy_link_change() provided by phylib. Otherwise, we implicitly know that\nthe phydev has the phylink-provided phylink_phy_change() callback, and\nwhen phylink is used, the PHY state machine always needs to be stopped/\nstarted on the suspend/resume path. The code is structured as such that\nif phydev-\u0026gt;phy_link_change() is absent, it is a matter of time until the\nkernel will crash - no need to further complicate the test.\n\nThus, for the situation where the PM is not managed b\n---truncated---(CVE-2025-37945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn\u0026apos;t scrubbed. That can lead skb\ninformation from one namespace to be \u0026quot;misused\u0026quot; in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host\u0026apos;s XFRM layer to the container\u0026apos;s XFRM\nlayer where it\u0026apos;s dropped and (2) the number of active skb extensions at\neach function.\n\n NETNS MARK IFACE TUPLE FUNC\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm4_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 gro_cells_receive\n .active_extensions = (__u8)2,\n [...]\n 4026533547 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 skb_do_redirect\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv_core\n .active_extensions = (__u8)2,\n [...]\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 udp_queue_rcv_one_skb\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_policy_check\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 security_xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container\u0026apos;s network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container\u0026apos;s netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can\u0026apos;t be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb-\u0026gt;mark and skb-\u0026gt;tstamp are not zeroed.(CVE-2025-37959)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemblock: Accept allocated memory before use in memblock_double_array()\n\nWhen increasing the array size in memblock_double_array() and the slab\nis not yet available, a call to memblock_find_in_range() is used to\nreserve/allocate memory. However, the range returned may not have been\naccepted, which can result in a crash when booting an SNP guest:\n\n RIP: 0010:memcpy_orig+0x68/0x130\n Code: ...\n RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006\n RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000\n RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00\n RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000\n R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78\n R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00\n memblock_double_array+0xff/0x310\n memblock_add_range+0x1fb/0x2f0\n memblock_reserve+0x4f/0xa0\n memblock_alloc_range_nid+0xac/0x130\n memblock_alloc_internal+0x53/0xc0\n memblock_alloc_try_nid+0x3d/0xa0\n swiotlb_init_remap+0x149/0x2f0\n mem_init+0xb/0xb0\n mm_core_init+0x8f/0x350\n start_kernel+0x17e/0x5d0\n x86_64_start_reservations+0x14/0x30\n x86_64_start_kernel+0x92/0xa0\n secondary_startup_64_no_verify+0x194/0x19b\n\nMitigate this by calling accept_memory() on the memory range returned\nbefore the slab is available.\n\nPrior to v6.12, the accept_memory() interface used a \u0026apos;start\u0026apos; and \u0026apos;end\u0026apos;\nparameter instead of \u0026apos;start\u0026apos; and \u0026apos;size\u0026apos;, therefore the accept_memory()\ncall must be adjusted to specify \u0026apos;start + size\u0026apos; for \u0026apos;end\u0026apos; when applying\nto kernels prior to v6.12.(CVE-2025-37960)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix uninit-value for saddr in do_output_route4\n\nsyzbot reports for uninit-value for the saddr argument [1].\ncommit 4754957f04f5 (\u0026quot;ipvs: do not use random local source address for\ntunnels\u0026quot;) already implies that the input value of saddr\nshould be ignored but the code is still reading it which can prevent\nto connect the route. Fix it by changing the argument to ret_saddr.\n\n[1]\nBUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4167 [inline]\n slab_alloc_node mm/slub.c:4210 [inline]\n __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367\n kmalloc_noprof include/linux/slab.h:905 [inline]\n ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]\n __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)\nHardware name: Google Google Compute Engi\n---truncated---(CVE-2025-37961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: leds: fix memory leak\n\nA network restart test on a router led to an out-of-memory condition,\nwhich was traced to a memory leak in the PHY LED trigger code.\n\nThe root cause is misuse of the devm API. The registration function\n(phy_led_triggers_register) is called from phy_attach_direct, not\nphy_probe, and the unregister function (phy_led_triggers_unregister)\nis called from phy_detach, not phy_remove. This means the register and\nunregister functions can be called multiple times for the same PHY\ndevice, but devm-allocated memory is not freed until the driver is\nunbound.\n\nThis also prevents kmemleak from detecting the leak, as the devm API\ninternally stores the allocated pointer.\n\nFix this by replacing devm_kzalloc/devm_kcalloc with standard\nkzalloc/kcalloc, and add the corresponding kfree calls in the unregister\npath.(CVE-2025-37989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()\n\nThe function brcmf_usb_dl_writeimage() calls the function\nbrcmf_usb_dl_cmd() but dose not check its return value. The\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized if the\nfunction brcmf_usb_dl_cmd() fails. It is dangerous to use\nuninitialized variables in the conditions.\n\nAdd error handling for brcmf_usb_dl_cmd() to jump to error\nhandling path if the brcmf_usb_dl_cmd() fails and the\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized.\n\nImprove the error message to report more detailed error\ninformation.(CVE-2025-37990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add missing rcu read protection for procfs content\n\nWhen the procfs content is generated for a bcm_op which is in the process\nto be removed the procfs output might show unreliable data (UAF).\n\nAs the removal of bcm_op\u0026apos;s is already implemented with rcu handling this\npatch adds the missing rcu_read_lock() and makes sure the list entries\nare properly removed under rcu protection.(CVE-2025-38003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add locking for bcm_op runtime updates\n\nThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via\nhrtimer. The content and also the length of the sequence can be changed\nresp reduced at runtime where the \u0026apos;currframe\u0026apos; counter is then set to zero.\n\nAlthough this appeared to be a safe operation the updates of \u0026apos;currframe\u0026apos;\ncan be triggered from user space and hrtimer context in bcm_can_tx().\nAnderson Nascimento created a proof of concept that triggered a KASAN\nslab-out-of-bounds read access which can be prevented with a spin_lock_bh.\n\nAt the rework of bcm_can_tx() the \u0026apos;count\u0026apos; variable has been moved into\nthe protected section as this variable can be modified from both contexts\ntoo.(CVE-2025-38004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: tegra: xusb: Use a bitmask for UTMI pad power state tracking\n\nThe current implementation uses bias_pad_enable as a reference count to\nmanage the shared bias pad for all UTMI PHYs. However, during system\nsuspension with connected USB devices, multiple power-down requests for\nthe UTMI pad result in a mismatch in the reference count, which in turn\nproduces warnings such as:\n\n[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763103] Call trace:\n[ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30\n[ 237.763110] phy_power_off+0x48/0x100\n[ 237.763113] tegra_xusb_enter_elpg+0x204/0x500\n[ 237.763119] tegra_xusb_suspend+0x48/0x140\n[ 237.763122] platform_pm_suspend+0x2c/0xb0\n[ 237.763125] dpm_run_callback.isra.0+0x20/0xa0\n[ 237.763127] __device_suspend+0x118/0x330\n[ 237.763129] dpm_suspend+0x10c/0x1f0\n[ 237.763130] dpm_suspend_start+0x88/0xb0\n[ 237.763132] suspend_devices_and_enter+0x120/0x500\n[ 237.763135] pm_suspend+0x1ec/0x270\n\nThe root cause was traced back to the dynamic power-down changes\nintroduced in commit a30951d31b25 (\u0026quot;xhci: tegra: USB2 pad power controls\u0026quot;),\nwhere the UTMI pad was being powered down without verifying its current\nstate. This unbalanced behavior led to discrepancies in the reference\ncount.\n\nTo rectify this issue, this patch replaces the single reference counter\nwith a bitmask, renamed to utmi_pad_enabled. Each bit in the mask\ncorresponds to one of the four USB2 PHYs, allowing us to track each pad\u0026apos;s\nenablement status individually.\n\nWith this change:\n - The bias pad is powered on only when the mask is clear.\n - Each UTMI pad is powered on or down based on its corresponding bit\n in the mask, preventing redundant operations.\n - The overall power state of the shared bias pad is maintained\n correctly during suspend/resume cycles.\n\nThe mutex used to prevent race conditions during UTMI pad enable/disable\noperations has been moved from the tegra186_utmi_bias_pad_power_on/off\nfunctions to the parent functions tegra186_utmi_pad_power_on/down. This\nchange ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices\n\nThe driver only offloads neighbors that are constructed on top of net\ndevices registered by it or their uppers (which are all Ethernet). The\ndevice supports GRE encapsulation and decapsulation of forwarded\ntraffic, but the driver will not offload dummy neighbors constructed on\ntop of GRE net devices as they are not uppers of its net devices:\n\n # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1\n # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 NOARP\n\n(Note that the neighbor is not marked with \u0026apos;offload\u0026apos;)\n\nWhen the driver is reloaded and the existing configuration is replayed,\nthe driver does not perform the same check regarding existing neighbors\nand offloads the previously added one:\n\n # devlink dev reload pci/0000:01:00.0\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 offload NOARP\n\nIf the neighbor is later deleted, the driver will ignore the\nnotification (given the GRE net device is not its upper) and will\ntherefore keep referencing freed memory, resulting in a use-after-free\n[1] when the net device is deleted:\n\n # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1\n # ip link del dev gre1\n\nFix by skipping neighbor replay if the net device for which the replay\nis performed is not our upper.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200\nRead of size 8 at addr ffff888155b0e420 by task ip/2282\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6f/0x350\n print_report+0x108/0x205\n kasan_report+0xdf/0x110\n mlxsw_sp_neigh_entry_update+0x1ea/0x200\n mlxsw_sp_router_rif_gone_sync+0x2a8/0x440\n mlxsw_sp_rif_destroy+0x1e9/0x750\n mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0\n mlxsw_sp_router_netdevice_event+0x3ac/0x15e0\n notifier_call_chain+0xca/0x150\n call_netdevice_notifiers_info+0x7f/0x100\n unregister_netdevice_many_notify+0xc8c/0x1d90\n rtnl_dellink+0x34e/0xa50\n rtnetlink_rcv_msg+0x6fb/0xb70\n netlink_rcv_skb+0x131/0x360\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Disable MACsec offload for uplink representor profile\n\nMACsec offload is not supported in switchdev mode for uplink\nrepresentors. When switching to the uplink representor profile, the\nMACsec offload feature must be cleared from the netdevice\u0026apos;s features.\n\nIf left enabled, attempts to add offloads result in a null pointer\ndereference, as the uplink representor does not support MACsec offload\neven though the feature bit remains set.\n\nClear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().\n\nKernel log:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]\nCPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__mutex_lock+0x128/0x1dd0\nCode: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff\nRSP: 0018:ffff888147a4f160 EFLAGS: 00010206\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078\nRBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000\nFS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x3d/0xa0\n ? exc_general_protection+0x144/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? __mutex_lock+0x128/0x1dd0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mutex_lock_io_nested+0x1ae0/0x1ae0\n ? lock_acquire+0x1c2/0x530\n ? macsec_upd_offload+0x145/0x380\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n ? __kasan_kmalloc+0x77/0x90\n ? __kmalloc_noprof+0x249/0x6b0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]\n macsec_update_offload+0x26c/0x820\n ? macsec_set_mac_address+0x4b0/0x4b0\n ? lockdep_hardirqs_on_prepare+0x284/0x400\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n macsec_upd_offload+0x2c8/0x380\n ? macsec_update_offload+0x820/0x820\n ? __nla_parse+0x22/0x30\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240\n genl_family_rcv_msg_doit+0x1cc/0x2a0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240\n ? cap_capable+0xd4/0x330\n genl_rcv_msg+0x3ea/0x670\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? macsec_update_offload+0x820/0x820\n netlink_rcv_skb+0x12b/0x390\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? netlink_ack+0xd80/0xd80\n ? rwsem_down_read_slowpath+0xf90/0xf90\n ? netlink_deliver_tap+0xcd/0xac0\n ? netlink_deliver_tap+0x155/0xac0\n ? _copy_from_iter+0x1bb/0x12c0\n genl_rcv+0x24/0x40\n netlink_unicast+0x440/0x700\n ? netlink_attachskb+0x760/0x760\n ? lock_acquire+0x1c2/0x530\n ? __might_fault+0xbb/0x170\n netlink_sendmsg+0x749/0xc10\n ? netlink_unicast+0x700/0x700\n ? __might_fault+0xbb/0x170\n ? netlink_unicast+0x700/0x700\n __sock_sendmsg+0xc5/0x190\n ____sys_sendmsg+0x53f/0x760\n ? import_iovec+0x7/0x10\n ? kernel_sendmsg+0x30/0x30\n ? __copy_msghdr+0x3c0/0x3c0\n ? filter_irq_stacks+0x90/0x90\n ? stack_depot_save_flags+0x28/0xa30\n ___sys_sen\n---truncated---(CVE-2025-38020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix \u0026quot;KASAN: slab-use-after-free Read in ib_register_device\u0026quot; problem\n\nCall Trace:\n\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n strlen+0x93/0xa0 lib/string.c:420\n __fortify_strlen include/linux/fortify-string.h:268 [inline]\n get_kobj_path_length lib/kobject.c:118 [inline]\n kobject_get_path+0x3f/0x2a0 lib/kobject.c:158\n kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545\n ib_register_device drivers/infiniband/core/device.c:1472 [inline]\n ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393\n rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552\n rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225\n nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796\n rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195\n rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmsg+0x16d/0x220 net/socket.c:2652\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThis problem is similar to the problem that the\ncommit 1d6a9e7449e2 (\u0026quot;RDMA/core: Fix use-after-free when rename device name\u0026quot;)\nfixes.\n\nThe root cause is: the function ib_device_rename() renames the name with\nlock. But in the function kobject_uevent(), this name is accessed without\nlock protection at the same time.\n\nThe solution is to add the lock protection when this name is accessed in\nthe function kobject_uevent().(CVE-2025-38022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.(CVE-2025-38024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled\n\nWhen attempting to enable MQPRIO while HTB offload is already\nconfigured, the driver currently returns `-EINVAL` and triggers a\n`WARN_ON`, leading to an unnecessary call trace.\n\nUpdate the code to handle this case more gracefully by returning\n`-EOPNOTSUPP` instead, while also providing a helpful user message.(CVE-2025-38039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn\n\nThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can\nrun on multiple platforms having different DMA architectures.\nOn some platforms there can be one FDQ for all flows in the RX channel\nwhile for others there is a separate FDQ for each flow in the RX channel.\n\nSo far we have been relying on the skip_fdq argument of\nk3_udma_glue_reset_rx_chn().\n\nInstead of relying on the user to provide this information, infer it\nbased on DMA architecture during k3_udma_glue_request_rx_chn() and save it\nin an internal flag \u0026apos;single_fdq\u0026apos;. Use that flag at\nk3_udma_glue_reset_rx_chn() to deicide if the FDQ needs\nto be cleared for every flow or just for flow 0.\n\nFixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.\n\n\u0026gt; ip link set eth1 down\n\u0026gt; ip link set eth0 down\n\u0026gt; ethtool -L eth0 rx 8\n\u0026gt; ip link set eth0 up\n\u0026gt; modprobe -r ti_am65_cpsw_nuss\n\n[ 103.045726] ------------[ cut here ]------------\n[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000\n[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas\np drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r\nfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool]\n[ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011\n[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)\n[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.154709] sp : ffff8000826ebbc0\n[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000\n[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0\n[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88\n[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000\n[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde\n[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000\n[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20\n[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100\n[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000\n[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000\n[ 103.229274] Call trace:\n[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)\n[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss]\n[ 103.244942] devm_action_release+0x14/0x20\n[ 103.249040] release_nodes+0x3c/0x68\n[ 103.252610] devres_release_all+0x8c/0xdc\n[ 103.256614] device_unbind_cleanup+0x18/0x60\n[ 103.260876] device_release_driver_internal+0xf8/0x178\n[ 103.266004] driver_detach+0x50/0x9c\n[ 103.269571] bus_remove_driver+0x6c/0xbc\n[ 103.273485] driver_unregister+0x30/0x60\n[ 103.277401] platform_driver_unregister+0x14/0x20\n[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss]\n[ 103.288620] __arm64_sys_delete_module+0x17c/0x25c\n[ 103.293404] invoke_syscall+0x44/0x100\n[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0\n[ 103.301845] do_el0_svc+0x1c/0x28\n[ 103.305155] el0_svc+0x28/0x98\n---truncated---(CVE-2025-38042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: set device_caps for 417\n\nThe video_device for the MPEG encoder did not set device_caps.\n\nAdd this, otherwise the video device can\u0026apos;t be registered (you get a\nWARN_ON instead).\n\nNot seen before since currently 417 support is disabled, but I found\nthis while experimenting with it.(CVE-2025-38044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: fix skb leaks\n\nA few error paths are missing a kfree_skb.(CVE-2025-38057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: prevent BUG_ON by blocking retries on failed device resumes\n\nA cache device failing to resume due to mapping errors should not be\nretried, as the failure leaves a partially initialized policy object.\nRepeating the resume operation risks triggering BUG_ON when reloading\ncache mappings into the incomplete policy object.\n\nReproduce steps:\n\n1. create a cache metadata consisting of 512 or more cache blocks,\n with some mappings stored in the first array block of the mapping\n array. Here we use cache_restore v1.0 to build the metadata.\n\ncat \u0026lt;\u0026lt;EOF \u0026gt;\u0026gt; cmeta.xml\n\u0026lt;superblock uuid=\u0026quot;\u0026quot; block_size=\u0026quot;128\u0026quot; nr_cache_blocks=\u0026quot;512\u0026quot; \\\npolicy=\u0026quot;smq\u0026quot; hint_width=\u0026quot;4\u0026quot;\u0026gt;\n \u0026lt;mappings\u0026gt;\n \u0026lt;mapping cache_block=\u0026quot;0\u0026quot; origin_block=\u0026quot;0\u0026quot; dirty=\u0026quot;false\u0026quot;/\u0026gt;\n \u0026lt;/mappings\u0026gt;\n\u0026lt;/superblock\u0026gt;\nEOF\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ncache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2\ndmsetup remove cmeta\n\n2. wipe the second array block of the mapping array to simulate\n data degradations.\n\nmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\nablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\ndd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock\n\n3. try bringing up the cache device. The resume is expected to fail\n due to the broken array block.\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndmsetup create cache --notable\ndmsetup load cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\ndmsetup resume cache\n\n4. try resuming the cache again. An unexpected BUG_ON is triggered\n while loading cache mappings.\n\ndmsetup resume cache\n\nKernel logs:\n\n(snip)\n------------[ cut here ]------------\nkernel BUG at drivers/md/dm-cache-policy-smq.c:752!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3\nRIP: 0010:smq_load_mapping+0x3e5/0x570\n\nFix by disallowing resume operations for devices that failed the\ninitial attempt.(CVE-2025-38066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race\n\nhuge_pmd_unshare() drops a reference on a page table that may have\npreviously been shared across processes, potentially turning it into a\nnormal page table used in another process in which unrelated VMAs can\nafterwards be installed.\n\nIf this happens in the middle of a concurrent gup_fast(), gup_fast() could\nend up walking the page tables of another process. While I don\u0026apos;t see any\nway in which that immediately leads to kernel memory corruption, it is\nreally weird and unexpected.\n\nFix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),\njust like we do in khugepaged when removing page tables for a THP\ncollapse.(CVE-2025-38085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix use-after-free in taprio_dev_notifier\n\nSince taprio\u2019s taprio_dev_notifier() isn\u2019t protected by an\nRCU read-side critical section, a race with advance_sched()\ncan lead to a use-after-free.\n\nAdding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: remove encap socket caching to avoid reference leak\n\nThe current scheme for caching the encap socket can lead to reference\nleaks when we try to delete the netns.\n\nThe reference chain is: xfrm_state -\u0026gt; enacp_sk -\u0026gt; netns\n\nSince the encap socket is a userspace socket, it holds a reference on\nthe netns. If we delete the espintcp state (through flush or\nindividual delete) before removing the netns, the reference on the\nsocket is dropped and the netns is correctly deleted. Otherwise, the\nnetns may not be reachable anymore (if all processes within the ns\nhave terminated), so we cannot delete the xfrm state to drop its\nreference on the socket.\n\nThis patch results in a small (~2% in my tests) performance\nregression.\n\nA GC-type mechanism could be added for the socket cache, to clear\nreferences if the state hasn\u0026apos;t been used \u0026quot;recently\u0026quot;, but it\u0026apos;s a lot\nmore complex than just not caching the socket.(CVE-2025-38097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: Fix use-after-free in page_pool_recycle_in_ring\n\nsyzbot reported a uaf in page_pool_recycle_in_ring:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\nRead of size 8 at addr ffff8880286045a0 by task syz.0.284/6943\n\nCPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]\n _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]\n page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]\n page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826\n page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]\n page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]\n napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036\n skb_pp_recycle net/core/skbuff.c:1047 [inline]\n skb_free_head net/core/skbuff.c:1094 [inline]\n skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125\n skb_release_all net/core/skbuff.c:1190 [inline]\n __kfree_skb net/core/skbuff.c:1204 [inline]\n sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242\n kfree_skb_reason include/linux/skbuff.h:1263 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]\n\nroot cause is:\n\npage_pool_recycle_in_ring\n ptr_ring_produce\n spin_lock(\u0026amp;r-\u0026gt;producer_lock);\n WRITE_ONCE(r-\u0026gt;queue[r-\u0026gt;producer++], ptr)\n //recycle last page to pool\n\t\t\t\tpage_pool_release\n\t\t\t\t page_pool_scrub\n\t\t\t\t page_pool_empty_ring\n\t\t\t\t ptr_ring_consume\n\t\t\t\t page_pool_return_page //release all page\n\t\t\t\t __page_pool_destroy\n\t\t\t\t free_percpu(pool-\u0026gt;recycle_stats);\n\t\t\t\t free(pool) //free\n\n spin_unlock(\u0026amp;r-\u0026gt;producer_lock); //pool-\u0026gt;ring uaf read\n recycle_stat_inc(pool, ring);\n\npage_pool can be free while page pool recycle the last page in ring.\nAdd producer-lock barrier to page_pool_release to prevent the page\npool from being free before all pages have been recycled.\n\nrecycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not\nenabled, which will trigger Wempty-body build warning. Add definition\nfor pool stat macro to fix warning.(CVE-2025-38129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u0026gt;sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0026apos;\u0026apos;\u0026apos;\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u0026gt;release() -\u0026gt; sock_map_close()\n sk_socket-\u0026gt;ops = NULL\n free(socket)\n sock-\u0026gt;ops-\u0026gt;sendmsg\n ^\n panic here\n\u0026apos;\u0026apos;\u0026apos;\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0026apos;\u0026apos;\u0026apos;\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u0026lt;=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0026apos;\u0026apos;\u0026apos;\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0026apos;t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0026apos;\u0026apos;\u0026apos;\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0026apos;\u0026apos;\u0026apos;(CVE-2025-38154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix panic when calling skb_linearize\n\nThe panic can be reproduced by executing the command:\n./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000\n\nThen a kernel panic was captured:\n\u0026apos;\u0026apos;\u0026apos;\n[ 657.460555] kernel BUG at net/core/skbuff.c:2178!\n[ 657.462680] Tainted: [W]=WARN\n[ 657.463287] Workqueue: events sk_psock_backlog\n...\n[ 657.469610] \u0026lt;TASK\u0026gt;\n[ 657.469738] ? die+0x36/0x90\n[ 657.469916] ? do_trap+0x1d0/0x270\n[ 657.470118] ? pskb_expand_head+0x612/0xf40\n[ 657.470376] ? pskb_expand_head+0x612/0xf40\n[ 657.470620] ? do_error_trap+0xa3/0x170\n[ 657.470846] ? pskb_expand_head+0x612/0xf40\n[ 657.471092] ? handle_invalid_op+0x2c/0x40\n[ 657.471335] ? pskb_expand_head+0x612/0xf40\n[ 657.471579] ? exc_invalid_op+0x2d/0x40\n[ 657.471805] ? asm_exc_invalid_op+0x1a/0x20\n[ 657.472052] ? pskb_expand_head+0xd1/0xf40\n[ 657.472292] ? pskb_expand_head+0x612/0xf40\n[ 657.472540] ? lock_acquire+0x18f/0x4e0\n[ 657.472766] ? find_held_lock+0x2d/0x110\n[ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10\n[ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470\n[ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10\n[ 657.473826] __pskb_pull_tail+0xfd/0x1d20\n[ 657.474062] ? __kasan_slab_alloc+0x4e/0x90\n[ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510\n[ 657.475392] ? __kasan_kmalloc+0xaa/0xb0\n[ 657.476010] sk_psock_backlog+0x5cf/0xd70\n[ 657.476637] process_one_work+0x858/0x1a20\n\u0026apos;\u0026apos;\u0026apos;\n\nThe panic originates from the assertion BUG_ON(skb_shared(skb)) in\nskb_linearize(). A previous commit(see Fixes tag) introduced skb_get()\nto avoid race conditions between skb operations in the backlog and skb\nrelease in the recvmsg path. However, this caused the panic to always\noccur when skb_linearize is executed.\n\nThe \u0026quot;--rx-strp 100000\u0026quot; parameter forces the RX path to use the strparser\nmodule which aggregates data until it reaches 100KB before calling sockmap\nlogic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.\n\nTo fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.\n\n\u0026apos;\u0026apos;\u0026apos;\nsk_psock_backlog:\n sk_psock_handle_skb\n skb_get(skb) \u0026lt;== we move it into \u0026apos;sk_psock_skb_ingress_enqueue\u0026apos;\n sk_psock_skb_ingress____________\n \u2193\n |\n | \u2192 sk_psock_skb_ingress_self\n | sk_psock_skb_ingress_enqueue\nsk_psock_verdict_apply_________________\u2191 skb_linearize\n\u0026apos;\u0026apos;\u0026apos;\n\nNote that for verdict_apply path, the skb_get operation is unnecessary so\nwe add \u0026apos;take_ref\u0026apos; param to control it\u0026apos;s behavior.(CVE-2025-38165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix ktls panic with sockmap\n\n[ 2172.936997] ------------[ cut here ]------------\n[ 2172.936999] kernel BUG at lib/iov_iter.c:629!\n......\n[ 2172.944996] PKRU: 55555554\n[ 2172.945155] Call Trace:\n[ 2172.945299] \u0026lt;TASK\u0026gt;\n[ 2172.945428] ? die+0x36/0x90\n[ 2172.945601] ? do_trap+0xdd/0x100\n[ 2172.945795] ? iov_iter_revert+0x178/0x180\n[ 2172.946031] ? iov_iter_revert+0x178/0x180\n[ 2172.946267] ? do_error_trap+0x7d/0x110\n[ 2172.946499] ? iov_iter_revert+0x178/0x180\n[ 2172.946736] ? exc_invalid_op+0x50/0x70\n[ 2172.946961] ? iov_iter_revert+0x178/0x180\n[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20\n[ 2172.947446] ? iov_iter_revert+0x178/0x180\n[ 2172.947683] ? iov_iter_revert+0x5c/0x180\n[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840\n[ 2172.948206] tls_sw_sendmsg+0x52/0x80\n[ 2172.948420] ? inet_sendmsg+0x1f/0x70\n[ 2172.948634] __sys_sendto+0x1cd/0x200\n[ 2172.948848] ? find_held_lock+0x2b/0x80\n[ 2172.949072] ? syscall_trace_enter+0x140/0x270\n[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170\n[ 2172.949595] ? find_held_lock+0x2b/0x80\n[ 2172.949817] ? syscall_trace_enter+0x140/0x270\n[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190\n[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0\n[ 2172.951036] __x64_sys_sendto+0x24/0x30\n[ 2172.951382] do_syscall_64+0x90/0x170\n......\n\nAfter calling bpf_exec_tx_verdict(), the size of msg_pl-\u0026gt;sg may increase,\ne.g., when the BPF program executes bpf_msg_push_data().\n\nIf the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,\nit will return -ENOSPC and attempt to roll back to the non-zero copy\nlogic. However, during rollback, msg-\u0026gt;msg_iter is reset, but since\nmsg_pl-\u0026gt;sg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n\u0026apos;\u0026apos;\u0026apos;\niov_iter_revert(\u0026amp;msg-\u0026gt;msg_iter, msg_pl-\u0026gt;sg.size - orig_size);\n\u0026apos;\u0026apos;\u0026apos;\n\nThe changes in this commit are based on the following considerations:\n\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n\n2. We can not calculate the correct number of bytes to revert msg_iter.\n\nAssume the original data is \u0026quot;abcdefgh\u0026quot; (8 bytes), and after 3 pushes\nby the BPF program, it becomes 11-byte data: \u0026quot;abc?de?fgh?\u0026quot;.\nThen, we set cork_bytes to 6, which means the first 6 bytes have been\nprocessed, and the remaining 5 bytes \u0026quot;?fgh?\u0026quot; will be cached until the\nlength meets the cork_bytes requirement.\n\nHowever, some data in \u0026quot;?fgh?\u0026quot; is not within \u0026apos;sg-\u0026gt;msg_iter\u0026apos;\n(but in msg_pl instead), especially the data \u0026quot;?\u0026quot; we pushed.\n\nSo it doesn\u0026apos;t seem as simple as just reverting through an offset of\nmsg_iter.\n\n3. For non-TLS sockets in tcp_bpf_sendmsg, when a \u0026quot;cork\u0026quot; situation occurs,\nthe user-space send() doesn\u0026apos;t return an error, and the returned length is\nthe same as the input length parameter, even if some data is cached.\n\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n\u0026apos;\u0026apos;\u0026apos;\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n\u0026apos;\u0026apos;\u0026apos;\n\nSo it\u0026apos;s ok to just return \u0026apos;copied\u0026apos; without error when a \u0026quot;cork\u0026quot; situation\noccurs.(CVE-2025-38166)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: make hfsc_qlen_notify() idempotent\n\nhfsc_qlen_notify() is not idempotent either and not friendly\nto its callers, like fq_codel_dequeue(). Let\u0026apos;s make it idempotent\nto ease qdisc_tree_reduce_backlog() callers\u0026apos; life:\n\n1. update_vf() decreases cl-\u0026gt;cl_nactive, so we can check whether it is\nnon-zero before calling it.\n\n2. eltree_remove() always removes RB node cl-\u0026gt;el_node, but we can use\n RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush\n\nIn KVM guests with Hyper-V hypercalls enabled, the hypercalls\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX\nallow a guest to request invalidation of portions of a virtual TLB.\nFor this, the hypercall parameter includes a list of GVAs that are supposed\nto be invalidated.\n\nHowever, when non-canonical GVAs are passed, there is currently no\nfiltering in place and they are eventually passed to checked invocations of\nINVVPID on Intel / INVLPGA on AMD. While AMD\u0026apos;s INVLPGA silently ignores\nnon-canonical addresses (effectively a no-op), Intel\u0026apos;s INVVPID explicitly\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():\n\n invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000\n WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482\n invvpid_error+0x91/0xa0 [kvm_intel]\n Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse\n CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)\n RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]\n Call Trace:\n vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]\n kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]\n\nHyper-V documents that invalid GVAs (those that are beyond a partition\u0026apos;s\nGVA space) are to be ignored. While not completely clear whether this\nruling also applies to non-canonical GVAs, it is likely fine to make that\nassumption, and manual testing on Azure confirms \u0026quot;real\u0026quot; Hyper-V interprets\nthe specification in the same way.\n\nSkip non-canonical GVAs when processing the list of address to avoid\ntripping the INVVPID failure. Alternatively, KVM could filter out \u0026quot;bad\u0026quot;\nGVAs before inserting into the FIFO, but practically speaking the only\ndownside of pushing validation to the final processing is that doing so\nis suboptimal for the guest, and no well-behaved guest will request TLB\nflushes for non-canonical addresses.(CVE-2025-38351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks\n\nAfter retrieving WMI data blocks in sysfs callbacks, check for the\nvalidity of them before dereferencing their content.(CVE-2025-38412)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: do not bypass hid_hw_raw_request\n\nhid_hw_raw_request() is actually useful to ensure the provided buffer\nand length are valid. Directly calling in the low level transport driver\nfunction bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)\n\nIn the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net-\u0026gt;xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net-\u0026gt;collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)\n\nIn the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: \u0026apos;dma\u0026apos; and \u0026apos;page_dma\u0026apos;. However, only \u0026apos;page_dma\u0026apos; was actually initialized and used to program the Rx descriptor. But \u0026apos;dma\u0026apos; was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized \u0026apos;dma\u0026apos; was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)\n\nIn the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 \u0026amp; 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Prevent VMA split of buffer mappings\n\nThe perf mmap code is careful about mmap()\u0026apos;ing the user page with the\nringbuffer and additionally the auxiliary buffer, when the event supports\nit. Once the first mapping is established, subsequent mapping have to use\nthe same offset and the same size in both cases. The reference counting for\nthe ringbuffer and the auxiliary buffer depends on this being correct.\n\nThough perf does not prevent that a related mapping is split via mmap(2),\nmunmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,\nwhich take reference counts, but then the subsequent perf_mmap_close()\ncalls are not longer fulfilling the offset and size checks. This leads to\nreference count leaks.\n\nAs perf already has the requirement for subsequent mappings to match the\ninitial mapping, the obvious consequence is that VMA splits, caused by\nresizing of a mapping or partial unmapping, have to be prevented.\n\nImplement the vm_operations_struct::may_split() callback and return\nunconditionally -EINVAL.\n\nThat ensures that the mapping offsets and sizes cannot be changed after the\nfact. Remapping to a different fixed address with the same size is still\npossible as it takes the references for the new mapping and drops those of\nthe old mapping.(CVE-2025-38563)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbenet: fix BUG when creating VFs\n\nbenet crashes as soon as SRIOV VFs are created:\n\n kernel BUG at mm/vmalloc.c:3457!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)\n [...]\n RIP: 0010:vunmap+0x5f/0x70\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __iommu_dma_free+0xe8/0x1c0\n be_cmd_set_mac_list+0x3fe/0x640 [be2net]\n be_cmd_set_mac+0xaf/0x110 [be2net]\n be_vf_eth_addr_config+0x19f/0x330 [be2net]\n be_vf_setup+0x4f7/0x990 [be2net]\n be_pci_sriov_configure+0x3a1/0x470 [be2net]\n sriov_numvfs_store+0x20b/0x380\n kernfs_fop_write_iter+0x354/0x530\n vfs_write+0x9b9/0xf60\n ksys_write+0xf3/0x1d0\n do_syscall_64+0x8c/0x3d0\n\nbe_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.\nFix it by freeing only after the lock has been released.(CVE-2025-38569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix double destruction of rsv_qp\n\nrsv_qp may be double destroyed in error flow, first in free_mr_init(),\nand then in hns_roce_exit(). Fix it by moving the free_mr_init() call\ninto hns_roce_v2_init().\n\nlist_del corruption, ffff589732eb9b50-\u0026gt;next is LIST_POISON1 (dead000000000100)\nWARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240\n...\nCall trace:\n __list_del_entry_valid+0x148/0x240\n hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]\n hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]\n hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]\n free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]\n hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]\n hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]\n __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]\n hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]\n hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]\n hclge_notify_roce_client+0x6c/0x160 [hclge]\n hclge_reset_rebuild+0x150/0x5c0 [hclge]\n hclge_reset+0x10c/0x140 [hclge]\n hclge_reset_subtask+0x80/0x104 [hclge]\n hclge_reset_service_task+0x168/0x3ac [hclge]\n hclge_service_task+0x50/0x100 [hclge]\n process_one_work+0x250/0x9a0\n worker_thread+0x324/0x990\n kthread+0x190/0x210\n ret_from_fork+0x10/0x18(CVE-2025-38582)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmci: Prevent the dispatching of uninitialized payloads\n\nThe reproducer executes the host\u0026apos;s unlocked_ioctl call in two different\ntasks. When init_context fails, the struct vmci_event_ctx is not fully\ninitialized when executing vmci_datagram_dispatch() to send events to all\nvm contexts. This affects the datagram taken from the datagram queue of\nits context by another task, because the datagram payload is not initialized\naccording to the size payload_size, which causes the kernel data to leak\nto the user space.\n\nBefore dispatching the datagram, and before setting the payload content,\nexplicitly set the payload content to 0 to avoid data leakage caused by\nincomplete payload initialization.(CVE-2025-38611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 (\u0026quot;pinmux: Use sequential access to access\ndesc-\u0026gt;pinmux data\u0026quot;) tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc-\u0026gt;mux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n cpu0 (process A) cpu1 (process B)\n\n pin_request() { pin_free() {\n\n mutex_lock()\n desc-\u0026gt;mux_usecount--; //becomes 0\n ..\n mutex_unlock()\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_usecount++; // becomes 1\n desc-\u0026gt;mux_owner = owner;\n mutex_unlock(desc-\u0026gt;mux)\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_owner = NULL;\n mutex_unlock(desc-\u0026gt;mux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.(CVE-2025-38632)\n\nIn the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro\u0026apos;s suggestion, it was fixed in the same manner.(CVE-2025-38653)\n\nIn the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)",
"id": "OESA-2025-2121",
"modified": "2026-08-06T11:09:12Z",
"published": "2025-09-05T11:09:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2121"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37885"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37912"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37989"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38066"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38166"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38177"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38412"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38494"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38500"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38563"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38569"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38582"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38632"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38671"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21678",
"CVE-2025-21723",
"CVE-2025-21864",
"CVE-2025-21947",
"CVE-2025-21955",
"CVE-2025-22007",
"CVE-2025-22021",
"CVE-2025-22056",
"CVE-2025-22057",
"CVE-2025-22063",
"CVE-2025-22064",
"CVE-2025-22086",
"CVE-2025-22089",
"CVE-2025-22106",
"CVE-2025-37749",
"CVE-2025-37752",
"CVE-2025-37772",
"CVE-2025-37789",
"CVE-2025-37794",
"CVE-2025-37829",
"CVE-2025-37834",
"CVE-2025-37859",
"CVE-2025-37875",
"CVE-2025-37879",
"CVE-2025-37885",
"CVE-2025-37909",
"CVE-2025-37911",
"CVE-2025-37912",
"CVE-2025-37932",
"CVE-2025-37945",
"CVE-2025-37959",
"CVE-2025-37960",
"CVE-2025-37961",
"CVE-2025-37989",
"CVE-2025-37990",
"CVE-2025-38003",
"CVE-2025-38004",
"CVE-2025-38010",
"CVE-2025-38019",
"CVE-2025-38020",
"CVE-2025-38022",
"CVE-2025-38024",
"CVE-2025-38039",
"CVE-2025-38042",
"CVE-2025-38044",
"CVE-2025-38057",
"CVE-2025-38066",
"CVE-2025-38085",
"CVE-2025-38087",
"CVE-2025-38097",
"CVE-2025-38129",
"CVE-2025-38154",
"CVE-2025-38165",
"CVE-2025-38166",
"CVE-2025-38177",
"CVE-2025-38201",
"CVE-2025-38351",
"CVE-2025-38412",
"CVE-2025-38494",
"CVE-2025-38500",
"CVE-2025-38533",
"CVE-2025-38540",
"CVE-2025-38563",
"CVE-2025-38569",
"CVE-2025-38582",
"CVE-2025-38611",
"CVE-2025-38632",
"CVE-2025-38653",
"CVE-2025-38671"
]
}
oesa-2025-2122
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
gtp: Destroy device along with udp socket's netns dismantle.
gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.
Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]
In this example, gtp0 is created in ns2, and the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1
Let's link the device to the socket's netns instead.
Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.
[0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) _syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) _sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated---(CVE-2025-21678)
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix possible crash when setting up bsg fails
If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value. Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)" will not be satisfied, preventing execution from entering bsg_remove_queue(), which could lead to the following crash:
BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace: <TASK> mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr] mpi3mr_remove+0x6f/0x340 [mpi3mr] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19d/0x220 unbind_store+0xa4/0xb0 kernfs_fop_write_iter+0x11f/0x200 vfs_write+0x1fc/0x3e0 ksys_write+0x67/0xe0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)
In the Linux kernel, the following vulnerability has been resolved:
tcp: drop secpath at the same time as we currently drop dst
Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns
The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free'd by skb_attempt_defer_free.
The problem happens when we defer freeing an skb (push it on one CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don't expect at this point.
We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.(CVE-2025-21864)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: prevent connection release during oplock break notification
ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.(CVE-2025-21955)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix error code in chan_alloc_skb_cb()
The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent.
However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as
pods' addresses are in the fd00::/8 ULA subnet and need to be replaced
with the node's external address. Cilium leverages Envoy to enforce L7
policies, and Envoy uses transparent sockets. Cilium inserts an iptables
prerouting rule that matches on -m socket --transparent and redirects
the packets to localhost, but it fails to match SNATed IPv6 packets due
to that missing conntrack lookup.(CVE-2025-22021)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_tunnel: fix geneve_opt type confusion addition
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] _syssendmsg+0x409/0x450 [ 7.002391] _sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse and dump code.(CVE-2025-22056)
In the Linux kernel, the following vulnerability has been resolved:
net: decrease cached dst counters in dst_release
Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:
Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30
Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.(CVE-2025-22057)
In the Linux kernel, the following vulnerability has been resolved:
netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed:
sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.
This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.(CVE-2025-22063)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: don't unregister hook when table is dormant
When nf_tables_updchain encounters an error, hook registration needs to be rolled back.
This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive).
Just move the assignment into the registration block.(CVE-2025-22064)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.
The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number.
Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 </TASK>(CVE-2025-22086)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Don't expose hw_counters outside of init net namespace
Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one:
[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: error_code(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] <TASK> [42021.953842] [<ffffffff86c58674>] ? show_regs+0x64/0x70 [42021.959030] [<ffffffff86c58468>] ? __die+0x78/0xc0 [42021.963874] [<ffffffff86c9ef75>] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [<ffffffff87674b92>] ? exc_page_fault+0x1a2/0x3c0 [42021.975549] [<ffffffff87801326>] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [<ffffffffc0775680>] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [<ffffffffc077564e>] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [<ffffffff86ac7f8e>] dev_attr_show+0x1e/0x50 [42022.000803] [<ffffffff86a3eeb1>] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [<ffffffff86a11134>] seq_read_iter+0xf4/0x410 [42022.011954] [<ffffffff869f4b2e>] vfs_read+0x16e/0x2f0 [42022.017058] [<ffffffff869f50ee>] ksys_read+0x6e/0xe0 [42022.022073] [<ffffffff8766f1ca>] do_syscall_64+0x6a/0xa0 [42022.027441] [<ffffffff8780013b>] entry_SYSCALL_64_after_hwframe+0x78/0xe2
The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*
The panic occurs because of casting the device pointer into an ib_device pointer using container_of() in hw_stat_device_show() is wrong and leads to a memory corruption.
However the real problem is that hw counters should never been exposed outside of the non-init net namespace.
Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization.
With this fix applied hw_counters are not available in a non-init net namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters
ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)
In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: unregister xdp rxq info in the reset path
vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace.
Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0
This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)
In the Linux kernel, the following vulnerability has been resolved:
net: ppp: Add bound checking for skb data on ppp_sync_txmung
Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets.
When ppp_sync_txmung receives an incoming package with an empty payload: (remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 }
from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,
it is not safe to access data[2].
[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: move the limit validation
It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed.
Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations:
tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1
This fixes the following syzkaller reported crash:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429 sfq_link net/sched/sch_sfq.c:203 [inline] sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231 sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493 sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339 qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035 dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311 netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline] dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix workqueue crash in cma_netevent_work_handler
struct rdma_cm_id has member "struct work_struct net_work" that is reused for enqueuing cma_netevent_work_handler()s onto cma_wq.
Below crash[1] can occur if more than one call to cma_netevent_callback() occurs in quick succession, which further enqueues cma_netevent_work_handler()s for the same rdma_cm_id, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cma_netevent_callback() and the 2nd INIT_WORK would overwrite the 1st work item (for the same rdma_cm_id), despite grabbing id_table_lock during enqueue.
Also drgn analysis [2] indicates the work item was likely overwritten.
Fix this by moving the INIT_WORK() to __rdma_create_id(), so that it doesn't race with any existing queue_work() or its worker thread.
[1] Trimmed crash stack:
BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Call Trace: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 =============================================
[2] drgn crash analysis:
>>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9)
Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);
>>> trace[8]["work"] (struct work_struct )0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head )0xffff924d075924c0, .prev = (struct list_head )0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, }
Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *)<absent>
In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work);
and get_work_pwq() is: static struct pool_workqueue get_work_pwq(struct work_struct work) { unsigned long data = atomic_long_read(&work->data);
if (data & WORK_STRUCT_PWQ)
return work_struct_pwq(data);
else
return NULL;
}
WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4)
But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================(CVE-2025-37772)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix nested key length validation in the set() action
It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Purge vif txq in ieee80211_do_stop()
After ieee80211_do_stop() SKB from vif's txq could still be processed. Indeed another concurrent vif schedule_and_wake_txq call could cause those packets to be dequeued (see ieee80211_handle_wake_tx_queue()) without checking the sdata current state.
Because vif.drv_priv is now cleared in this function, this could lead to driver crash.
For example in ath12k, ahvif is store in vif.drv_priv. Thus if ath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below.
Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158
To avoid that, empty vif's txq at ieee80211_do_stop() so no packet could be dequeued after ieee80211_do_stop() (new packets cannot be queued because SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()
cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37829)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: don't try to reclaim hwpoison folio
Syzkaller reports a bug as follows:
Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20
I can reproduce this issue with the following steps:
1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.
2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.
3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared.
To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list.(CVE-2025-37834)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: avoid infinite loop to schedule delayed worker
We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1].
Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally.
This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry().
[1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)
In the Linux kernel, the following vulnerability has been resolved:
igc: fix PTM cycle trigger logic
Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction.
The issue can be reproduced with the following:
$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m
Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue.
PHC2SYS exits with:
"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails
This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM.
The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle.
When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump.
With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)
In the Linux kernel, the following vulnerability has been resolved:
9p/net: fix improper handling of bogus negative read/write replies
In p9_client_write() and p9_client_read_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed.
Make variables unsigned to avoid this problem.
The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)(CVE-2025-37879)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Reset IRTE to host control if new route isn't postable
Restore an IRTE back to host control (remapped or posted MSI mode) if the new GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.
The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.(CVE-2025-37885)
In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: Fix memleak issue when GSO enabled
Always map the skb to the LS descriptor. Previously skb was
mapped to EXT descriptor when the number of fragments is zero with
GSO enabled. Mapping the skb to EXT descriptor prevents it from
being freed, leading to a memory leak(CVE-2025-37909)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix out-of-bound memcpy() during ethtool -w
When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption:
BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80
...
This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf.
In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information.
This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.(CVE-2025-37911)
In the Linux kernel, the following vulnerability has been resolved:
ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()
As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI pointer values"), we need to perform a null pointer check on the return value of ice_get_vf_vsi() before using it.(CVE-2025-37912)
In the Linux kernel, the following vulnerability has been resolved:
sch_htb: make htb_qlen_notify() idempotent
htb_qlen_notify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fq_codel_dequeue().
Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life.(CVE-2025-37932)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY
DSA has 2 kinds of drivers:
- Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
- Those who don't: all others. The above methods should be optional.
For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(), and dsa_switch_resume() calls dsa_user_resume() -> phylink_start(). These seem good candidates for setting mac_managed_pm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.
Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full), I have noticed that the following warning from mdio_bus_phy_resume() is triggered:
WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&
phydev->state != PHY_UP);
because the PHY state machine is running.
It's running as a result of a previous dsa_user_open() -> ... -> phylink_start() -> phy_start() having been initiated by the user.
The previous mdio_bus_phy_suspend() was supposed to have called phy_stop_machine(), but it didn't. So this is why the PHY is in state PHY_NOLINK by the time mdio_bus_phy_resume() runs.
mdio_bus_phy_suspend() did not call phy_stop_machine() because for phylink, the phydev->adjust_link function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible.
This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming mac_managed_pm is set correctly, a quick search indicates the following other drivers might be affected:
$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5_main.c drivers/net/ethernet/microchip/lan966x/lan966x_main.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/freescale/ucc_geth.c drivers/net/ethernet/freescale/enetc/enetc_pf_common.c drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/prestera_main.c drivers/net/ethernet/mediatek/mtk_eth_soc.c drivers/net/ethernet/altera/altera_tse_main.c drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c drivers/net/ethernet/meta/fbnic/fbnic_phylink.c drivers/net/ethernet/tehuti/tn40_phy.c drivers/net/ethernet/mscc/ocelot_net.c
Make the existing conditions dependent on the PHY device having a phydev->phy_link_change() implementation equal to the default phy_link_change() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylink_phy_change() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phy_link_change() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.
Thus, for the situation where the PM is not managed b ---truncated---(CVE-2025-37945)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Scrub packet on bpf_redirect_peer
When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace.
As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function.
NETNS MARK IFACE TUPLE FUNC
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb
.active_extensions = (__u8)2,
4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive
.active_extensions = (__u8)2,
[...]
4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core
.active_extensions = (__u8)2,
[...]
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session
.active_extensions = (__u8)2,
4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)
.active_extensions = (__u8)2,
In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption.
This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.(CVE-2025-37959)
In the Linux kernel, the following vulnerability has been resolved:
memblock: Accept allocated memory before use in memblock_double_array()
When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest:
RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b
Mitigate this by calling accept_memory() on the memory range returned before the slab is available.
Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.(CVE-2025-37960)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix uninit-value for saddr in do_output_route4
syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr.
[1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e
CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---(CVE-2025-37961)
In the Linux kernel, the following vulnerability has been resolved:
net: phy: leds: fix memory leak
A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code.
The root cause is misuse of the devm API. The registration function (phy_led_triggers_register) is called from phy_attach_direct, not phy_probe, and the unregister function (phy_led_triggers_unregister) is called from phy_detach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound.
This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer.
Fix this by replacing devm_kzalloc/devm_kcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.(CVE-2025-37989)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()
The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions.
Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized.
Improve the error message to report more detailed error information.(CVE-2025-37990)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add missing rcu read protection for procfs content
When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF).
As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.(CVE-2025-38003)
In the Linux kernel, the following vulnerability has been resolved:
can: bcm: add locking for bcm_op runtime updates
The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero.
Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.(CVE-2025-38004)
In the Linux kernel, the following vulnerability has been resolved:
phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking
The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as:
[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270
The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count.
To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually.
With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles.
The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices
The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices:
# ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP
(Note that the neighbor is not marked with 'offload')
When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one:
# devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP
If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted:
# ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1
Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6f/0x350 print_report+0x108/0x205 kasan_report+0xdf/0x110 mlxsw_sp_neigh_entry_update+0x1ea/0x200 mlxsw_sp_router_rif_gone_sync+0x2a8/0x440 mlxsw_sp_rif_destroy+0x1e9/0x750 mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0 mlxsw_sp_router_netdevice_event+0x3ac/0x15e0 notifier_call_chain+0xca/0x150 call_netdevice_notifiers_info+0x7f/0x100 unregister_netdevice_many_notify+0xc8c/0x1d90 rtnl_dellink+0x34e/0xa50 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Disable MACsec offload for uplink representor profile
MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features.
If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set.
Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().
Kernel log:
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: <TASK> ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 _syssendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sen ---truncated---(CVE-2025-38020)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem
Call Trace:
__dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] _syssendmsg+0xa95/0xc70 net/socket.c:2566 _sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes.
The root cause is: the function ib_device_rename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time.
The solution is to add the lock protection when this name is accessed in the function kobject_uevent().(CVE-2025-38022)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug
Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur.
The solution is to let rxe_cleanup do all the work.(CVE-2025-38024)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled
When attempting to enable MQPRIO while HTB offload is already
configured, the driver currently returns -EINVAL and triggers a
WARN_ON, leading to an unnecessary call trace.
Update the code to handle this case more gracefully by returning
-EOPNOTSUPP instead, while also providing a helpful user message.(CVE-2025-38039)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn
The user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can run on multiple platforms having different DMA architectures. On some platforms there can be one FDQ for all flows in the RX channel while for others there is a separate FDQ for each flow in the RX channel.
So far we have been relying on the skip_fdq argument of k3_udma_glue_reset_rx_chn().
Instead of relying on the user to provide this information, infer it based on DMA architecture during k3_udma_glue_request_rx_chn() and save it in an internal flag 'single_fdq'. Use that flag at k3_udma_glue_reset_rx_chn() to deicide if the FDQ needs to be cleared for every flow or just for flow 0.
Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.
> ip link set eth1 down > ip link set eth0 down > ethtool -L eth0 rx 8 > ip link set eth0 up > modprobe -r ti_am65_cpsw_nuss
[ 103.045726] ------------[ cut here ]------------ [ 103.050505] k3_knav_desc_pool size 512000 != avail 64000 [ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool] [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT) [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.154709] sp : ffff8000826ebbc0 [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [ 103.229274] Call trace: [ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P) [ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss] [ 103.244942] devm_action_release+0x14/0x20 [ 103.249040] release_nodes+0x3c/0x68 [ 103.252610] devres_release_all+0x8c/0xdc [ 103.256614] device_unbind_cleanup+0x18/0x60 [ 103.260876] device_release_driver_internal+0xf8/0x178 [ 103.266004] driver_detach+0x50/0x9c [ 103.269571] bus_remove_driver+0x6c/0xbc [ 103.273485] driver_unregister+0x30/0x60 [ 103.277401] platform_driver_unregister+0x14/0x20 [ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss] [ 103.288620] __arm64_sys_delete_module+0x17c/0x25c [ 103.293404] invoke_syscall+0x44/0x100 [ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0 [ 103.301845] do_el0_svc+0x1c/0x28 [ 103.305155] el0_svc+0x28/0x98 ---truncated---(CVE-2025-38042)
In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: set device_caps for 417
The video_device for the MPEG encoder did not set device_caps.
Add this, otherwise the video device can't be registered (you get a WARN_ON instead).
Not seen before since currently 417 support is disabled, but I found this while experimenting with it.(CVE-2025-38044)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: fix skb leaks
A few error paths are missing a kfree_skb.(CVE-2025-38057)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: prevent BUG_ON by blocking retries on failed device resumes
A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object.
Reproduce steps:
- create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.
cat <<EOF >> cmeta.xml <superblock uuid="" block_size="128" nr_cache_blocks="512" \ policy="smq" hint_width="4"> <mappings> <mapping cache_block="0" origin_block="0" dirty="false"/> </mappings> </superblock> EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta
- wipe the second array block of the mapping array to simulate data degradations.
mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock
- try bringing up the cache device. The resume is expected to fail due to the broken array block.
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache
- try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.
dmsetup resume cache
Kernel logs:
(snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570
Fix by disallowing resume operations for devices that failed the initial attempt.(CVE-2025-38066)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race
huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed.
If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected.
Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse.(CVE-2025-38085)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: fix use-after-free in taprio_dev_notifier
Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free.
Adding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.
The reference chain is: xfrm_state -> enacp_sk -> netns
Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.
This patch results in a small (~2% in my tests) performance regression.
A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.(CVE-2025-38097)
In the Linux kernel, the following vulnerability has been resolved:
page_pool: Fix use-after-free in page_pool_recycle_in_ring
syzbot reported a uaf in page_pool_recycle_in_ring:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943
CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]
root cause is:
page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free
spin_unlock(&r->producer_lock); //pool->ring uaf read
recycle_stat_inc(pool, ring);
page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled.
recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.(CVE-2025-38129)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.
Race conditions: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''
The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''
Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread and close() thread.
The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix panic when calling skb_linearize
The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000
Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events sk_psock_backlog ... [ 657.469610] <TASK> [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? do_trap+0x1d0/0x270 [ 657.470118] ? pskb_expand_head+0x612/0xf40 [ 657.470376] ? pskb_expand_head+0x612/0xf40 [ 657.470620] ? do_error_trap+0xa3/0x170 [ 657.470846] ? pskb_expand_head+0x612/0xf40 [ 657.471092] ? handle_invalid_op+0x2c/0x40 [ 657.471335] ? pskb_expand_head+0x612/0xf40 [ 657.471579] ? exc_invalid_op+0x2d/0x40 [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20 [ 657.472052] ? pskb_expand_head+0xd1/0xf40 [ 657.472292] ? pskb_expand_head+0x612/0xf40 [ 657.472540] ? lock_acquire+0x18f/0x4e0 [ 657.472766] ? find_held_lock+0x2d/0x110 [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10 [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470 [ 657.473537] ? __pfxlockrelease.isra.0+0x10/0x10 [ 657.473826] pskb_pull_tail+0xfd/0x1d20 [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90 [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510 [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0 [ 657.476010] sk_psock_backlog+0x5cf/0xd70 [ 657.476637] process_one_work+0x858/0x1a20 '''
The panic originates from the assertion BUG_ON(skb_shared(skb)) in skb_linearize(). A previous commit(see Fixes tag) introduced skb_get() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed.
The "--rx-strp 100000" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.
To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.
''' sk_psock_backlog: sk_psock_handle_skb skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue' sk_psock_skb_ingress__ ↓ | | → sk_psock_skb_ingress_self | sk_psock_skb_ingress_enqueue sk_psock_verdict_apply___↑ skb_linearize '''
Note that for verdict_apply path, the skb_get operation is unnecessary so we add 'take_ref' param to control it's behavior.(CVE-2025-38165)
In the Linux kernel, the following vulnerability has been resolved:
bpf: fix ktls panic with sockmap
[ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] <TASK> [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ......
After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data().
If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); '''
The changes in this commit are based on the following considerations:
-
When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic.
-
We can not calculate the correct number of bytes to revert msg_iter.
Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement.
However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed.
So it doesn't seem as simple as just reverting through an offset of msg_iter.
- For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached.
Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; '''
So it's ok to just return 'copied' without error when a "cork" situation occurs.(CVE-2025-38166)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: make hfsc_qlen_notify() idempotent
hfsc_qlen_notify() is not idempotent either and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life:
-
update_vf() decreases cl->cl_nactive, so we can check whether it is non-zero before calling it.
-
eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush
In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated.
However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way.
Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.(CVE-2025-38351)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks
After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.(CVE-2025-38412)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: do not bypass hid_hw_raw_request
hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)
In the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net->xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net->collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)
In the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)
In the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Prevent VMA split of buffer mappings
The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct.
Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks.
As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented.
Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL.
That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.(CVE-2025-38563)
In the Linux kernel, the following vulnerability has been resolved:
benet: fix BUG when creating VFs
benet crashes as soon as SRIOV VFs are created:
kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: <TASK> __iommu_dma_free+0xe8/0x1c0 be_cmd_set_mac_list+0x3fe/0x640 [be2net] be_cmd_set_mac+0xaf/0x110 [be2net] be_vf_eth_addr_config+0x19f/0x330 [be2net] be_vf_setup+0x4f7/0x990 [be2net] be_pci_sriov_configure+0x3a1/0x470 [be2net] sriov_numvfs_store+0x20b/0x380 kernfs_fop_write_iter+0x354/0x530 vfs_write+0x9b9/0xf60 ksys_write+0xf3/0x1d0 do_syscall_64+0x8c/0x3d0
be_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh. Fix it by freeing only after the lock has been released.(CVE-2025-38569)
In the Linux kernel, the following vulnerability has been resolved:
vmci: Prevent the dispatching of uninitialized payloads
The reproducer executes the host's unlocked_ioctl call in two different tasks. When init_context fails, the struct vmci_event_ctx is not fully initialized when executing vmci_datagram_dispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space.
Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization.(CVE-2025-38611)
In the Linux kernel, the following vulnerability has been resolved:
pinmux: fix race causing mux_owner NULL with active mux_usecount
commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer.
The issue occurs due to the following interleaving:
cpu0 (process A) cpu1 (process B)
pin_request() { pin_free() {
mutex_lock()
desc->mux_usecount--; //becomes 0
..
mutex_unlock()
mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux)
mutex_lock(desc->mux)
desc->mux_owner = NULL;
mutex_unlock(desc->mux)
This sequence leads to a state where the pin appears to be in use
(mux_usecount == 1) but has no owner (mux_owner == NULL), which can
cause NULL pointer on next pin_request on the same pin.
Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned.(CVE-2025-38632)
In the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro's suggestion, it was fixed in the same manner.(CVE-2025-38653)
In the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"perf-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-108.0.0.114.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"perf-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-108.0.0.114.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-108.0.0.114.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\ngtp: Destroy device along with udp socket\u0026apos;s netns dismantle.\n\ngtp_newlink() links the device to a list in dev_net(dev) instead of\nsrc_net, where a udp tunnel socket is created.\n\nEven when src_net is removed, the device stays alive on dev_net(dev).\nThen, removing src_net triggers the splat below. [0]\n\nIn this example, gtp0 is created in ns2, and the udp socket is created\nin ns1.\n\n ip netns add ns1\n ip netns add ns2\n ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn\n ip netns del ns1\n\nLet\u0026apos;s link the device to the socket\u0026apos;s netns instead.\n\nNow, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove\nall gtp devices in the netns.\n\n[0]:\nref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at\n sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)\n inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)\n __sock_create (net/socket.c:1558)\n udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)\n gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)\n gtp_create_sockets (drivers/net/gtp.c:1447)\n gtp_newlink (drivers/net/gtp.c:1507)\n rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)\n rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)\n netlink_rcv_skb (net/netlink/af_netlink.c:2542)\n netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)\n netlink_sendmsg (net/netlink/af_netlink.c:1891)\n ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)\n ___sys_sendmsg (net/socket.c:2639)\n __sys_sendmsg (net/socket.c:2669)\n do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n\nWARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\nModules linked in:\nCPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: netns cleanup_net\nRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)\nCode: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 \u0026lt;0f\u0026gt; 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89\nRSP: 0018:ff11000009a07b60 EFLAGS: 00010286\nRAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c\nRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae\nR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0\nR13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn (kernel/panic.c:748)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:285)\n ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)\n ? kfree (mm/slub.c:4613 mm/slub.c:4761)\n net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)\n cleanup_net (net/core/net_namespace.c:664 (discriminator 3))\n process_one_work (kernel/workqueue.c:3229)\n worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391\n---truncated---(CVE-2025-21678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix possible crash when setting up bsg fails\n\nIf bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value.\nConsequently, in mpi3mr_bsg_exit(), the condition \u0026quot;if(!mrioc-\u0026gt;bsg_queue)\u0026quot;\nwill not be satisfied, preventing execution from entering\nbsg_remove_queue(), which could lead to the following crash:\n\nBUG: kernel NULL pointer dereference, address: 000000000000041c\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]\n mpi3mr_remove+0x6f/0x340 [mpi3mr]\n pci_device_remove+0x3f/0xb0\n device_release_driver_internal+0x19d/0x220\n unbind_store+0xa4/0xb0\n kernfs_fop_write_iter+0x11f/0x200\n vfs_write+0x1fc/0x3e0\n ksys_write+0x67/0xe0\n do_syscall_64+0x38/0x80\n entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: drop secpath at the same time as we currently drop dst\n\nXiumei reported hitting the WARN in xfrm6_tunnel_net_exit while\nrunning tests that boil down to:\n - create a pair of netns\n - run a basic TCP test over ipcomp6\n - delete the pair of netns\n\nThe xfrm_state found on spi_byaddr was not deleted at the time we\ndelete the netns, because we still have a reference on it. This\nlingering reference comes from a secpath (which holds a ref on the\nxfrm_state), which is still attached to an skb. This skb is not\nleaked, it ends up on sk_receive_queue and then gets defer-free\u0026apos;d by\nskb_attempt_defer_free.\n\nThe problem happens when we defer freeing an skb (push it on one CPU\u0026apos;s\ndefer_list), and don\u0026apos;t flush that list before the netns is deleted. In\nthat case, we still have a reference on the xfrm_state that we don\u0026apos;t\nexpect at this point.\n\nWe already drop the skb\u0026apos;s dst in the TCP receive path when it\u0026apos;s no\nlonger needed, so let\u0026apos;s also drop the secpath. At this point,\ntcp_filter has already called into the LSM hooks that may require the\nsecpath, so it should not be needed anymore. However, in some of those\nplaces, the MPTCP extension has just been attached to the skb, so we\ncannot simply drop all extensions.(CVE-2025-21864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent connection release during oplock break notification\n\nksmbd_work could be freed when after connection release.\nIncrement r_count of ksmbd_conn to indicate that requests\nare not finished yet and to not release the connection.(CVE-2025-21955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix error code in chan_alloc_skb_cb()\n\nThe chan_alloc_skb_cb() function is supposed to return error pointers on\nerror. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: socket: Lookup orig tuple for IPv6 SNAT\n\nnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to\nrestore the original 5-tuple in case of SNAT, to be able to find the\nright socket (if any). Then socket_match() can correctly check whether\nthe socket was transparent.\n\nHowever, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this\nconntrack lookup, making xt_socket fail to match on the socket when the\npacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.\n\nIPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as\npods\u0026apos; addresses are in the fd00::/8 ULA subnet and need to be replaced\nwith the node\u0026apos;s external address. Cilium leverages Envoy to enforce L7\npolicies, and Envoy uses transparent sockets. Cilium inserts an iptables\nprerouting rule that matches on `-m socket --transparent` and redirects\nthe packets to localhost, but it fails to match SNATed IPv6 packets due\nto that missing conntrack lookup.(CVE-2025-22021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_tunnel: fix geneve_opt type confusion addition\n\nWhen handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the\nparsing logic should place every geneve_opt structure one by one\ncompactly. Hence, when deciding the next geneve_opt position, the\npointer addition should be in units of char *.\n\nHowever, the current implementation erroneously does type conversion\nbefore the addition, which will lead to heap out-of-bounds write.\n\n[ 6.989857] ==================================================================\n[ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70\n[ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178\n[ 6.991162]\n[ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1\n[ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[ 6.992281] Call Trace:\n[ 6.992423] \u0026lt;TASK\u0026gt;\n[ 6.992586] dump_stack_lvl+0x44/0x5c\n[ 6.992801] print_report+0x184/0x4be\n[ 6.993790] kasan_report+0xc5/0x100\n[ 6.994252] kasan_check_range+0xf3/0x1a0\n[ 6.994486] memcpy+0x38/0x60\n[ 6.994692] nft_tunnel_obj_init+0x977/0xa70\n[ 6.995677] nft_obj_init+0x10c/0x1b0\n[ 6.995891] nf_tables_newobj+0x585/0x950\n[ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020\n[ 6.998997] nfnetlink_rcv+0x1df/0x220\n[ 6.999537] netlink_unicast+0x395/0x530\n[ 7.000771] netlink_sendmsg+0x3d0/0x6d0\n[ 7.001462] __sock_sendmsg+0x99/0xa0\n[ 7.001707] ____sys_sendmsg+0x409/0x450\n[ 7.002391] ___sys_sendmsg+0xfd/0x170\n[ 7.003145] __sys_sendmsg+0xea/0x170\n[ 7.004359] do_syscall_64+0x5e/0x90\n[ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 7.006127] RIP: 0033:0x7ec756d4e407\n[ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407\n[ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003\n[ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000\n[ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\n[ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8\n\nFix this bug with correct pointer addition and conversion in parse\nand dump code.(CVE-2025-22056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: decrease cached dst counters in dst_release\n\nUpstream fix ac888d58869b (\u0026quot;net: do not delay dst_entries_add() in\ndst_release()\u0026quot;) moved decrementing the dst count from dst_destroy to\ndst_release to avoid accessing already freed data in case of netns\ndismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels\nare used, this fix is incomplete as the same issue will be seen for\ncached dsts:\n\n Unable to handle kernel paging request at virtual address ffff5aabf6b5c000\n Call trace:\n percpu_counter_add_batch+0x3c/0x160 (P)\n dst_release+0xec/0x108\n dst_cache_destroy+0x68/0xd8\n dst_destroy+0x13c/0x168\n dst_destroy_rcu+0x1c/0xb0\n rcu_do_batch+0x18c/0x7d0\n rcu_core+0x174/0x378\n rcu_core_si+0x18/0x30\n\nFix this by invalidating the cache, and thus decrementing cached dst\ncounters, in dst_release too.(CVE-2025-22057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets\n\nWhen calling netlbl_conn_setattr(), addr-\u0026gt;sa_family is used\nto determine the function behavior. If sk is an IPv4 socket,\nbut the connect function is called with an IPv6 address,\nthe function calipso_sock_setattr() is triggered.\nInside this function, the following code is executed:\n\nsk_fullsock(__sk) ? inet_sk(__sk)-\u0026gt;pinet6 : NULL;\n\nSince sk is an IPv4 socket, pinet6 is NULL, leading to a\nnull pointer dereference.\n\nThis patch fixes the issue by checking if inet6_sk(sk)\nreturns a NULL pointer before accessing pinet6.(CVE-2025-22063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don\u0026apos;t unregister hook when table is dormant\n\nWhen nf_tables_updchain encounters an error, hook registration needs to\nbe rolled back.\n\nThis should only be done if the hook has been registered, which won\u0026apos;t\nhappen when the table is flagged as dormant (inactive).\n\nJust move the assignment into the registration block.(CVE-2025-22064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow\n\nWhen cur_qp isn\u0026apos;t NULL, in order to avoid fetching the QP from\nthe radix tree again we check if the next cqe QP is identical to\nthe one we already have.\n\nThe bug however is that we are checking if the QP is identical by\nchecking the QP number inside the CQE against the QP number inside the\nmlx5_ib_qp, but that\u0026apos;s wrong since the QP number from the CQE is from\nFW so it should be matched against mlx5_core_qp which is our FW QP\nnumber.\n\nOtherwise we could use the wrong QP when handling a CQE which could\ncause the kernel trace below.\n\nThis issue is mainly noticeable over QPs 0 \u0026amp; 1, since for now they are\nthe only QPs in our driver whereas the QP number inside mlx5_ib_qp\ndoesn\u0026apos;t match the QP number inside mlx5_core_qp.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\n RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 \u0026lt;0f\u0026gt; b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21\n RSP: 0018:ffff88810511bd60 EFLAGS: 00010046\n RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a\n RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10\n R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000\n R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0\n FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n __ib_process_cq+0x5a/0x150 [ib_core]\n ib_cq_poll_work+0x31/0x90 [ib_core]\n process_one_work+0x169/0x320\n worker_thread+0x288/0x3a0\n ? work_busy+0xb0/0xb0\n kthread+0xd7/0x1f0\n ? kthreads_online_cpu+0x130/0x130\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork+0x2d/0x50\n ? kthreads_online_cpu+0x130/0x130\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;(CVE-2025-22086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Don\u0026apos;t expose hw_counters outside of init net namespace\n\nCommit 467f432a521a (\u0026quot;RDMA/core: Split port and device counter sysfs\nattributes\u0026quot;) accidentally almost exposed hw counters to non-init net\nnamespaces. It didn\u0026apos;t expose them fully, as an attempt to read any of\nthose counters leads to a crash like this one:\n\n[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028\n[42021.814463] #PF: supervisor read access in kernel mode\n[42021.819549] #PF: error_code(0x0000) - not-present page\n[42021.824636] PGD 0 P4D 0\n[42021.827145] Oops: 0000 [#1] SMP PTI\n[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX\n[42021.841697] Hardware name: XXX\n[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff \u0026lt;48\u0026gt; 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48\n[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287\n[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000\n[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0\n[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000\n[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530\n[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000\n[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000\n[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0\n[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[42021.949324] Call Trace:\n[42021.951756] \u0026lt;TASK\u0026gt;\n[42021.953842] [\u0026lt;ffffffff86c58674\u0026gt;] ? show_regs+0x64/0x70\n[42021.959030] [\u0026lt;ffffffff86c58468\u0026gt;] ? __die+0x78/0xc0\n[42021.963874] [\u0026lt;ffffffff86c9ef75\u0026gt;] ? page_fault_oops+0x2b5/0x3b0\n[42021.969749] [\u0026lt;ffffffff87674b92\u0026gt;] ? exc_page_fault+0x1a2/0x3c0\n[42021.975549] [\u0026lt;ffffffff87801326\u0026gt;] ? asm_exc_page_fault+0x26/0x30\n[42021.981517] [\u0026lt;ffffffffc0775680\u0026gt;] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]\n[42021.988482] [\u0026lt;ffffffffc077564e\u0026gt;] ? hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.995438] [\u0026lt;ffffffff86ac7f8e\u0026gt;] dev_attr_show+0x1e/0x50\n[42022.000803] [\u0026lt;ffffffff86a3eeb1\u0026gt;] sysfs_kf_seq_show+0x81/0xe0\n[42022.006508] [\u0026lt;ffffffff86a11134\u0026gt;] seq_read_iter+0xf4/0x410\n[42022.011954] [\u0026lt;ffffffff869f4b2e\u0026gt;] vfs_read+0x16e/0x2f0\n[42022.017058] [\u0026lt;ffffffff869f50ee\u0026gt;] ksys_read+0x6e/0xe0\n[42022.022073] [\u0026lt;ffffffff8766f1ca\u0026gt;] do_syscall_64+0x6a/0xa0\n[42022.027441] [\u0026lt;ffffffff8780013b\u0026gt;] entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe problem can be reproduced using the following steps:\n ip netns add foo\n ip netns exec foo bash\n cat /sys/class/infiniband/mlx4_0/hw_counters/*\n\nThe panic occurs because of casting the device pointer into an\nib_device pointer using container_of() in hw_stat_device_show() is\nwrong and leads to a memory corruption.\n\nHowever the real problem is that hw counters should never been exposed\noutside of the non-init net namespace.\n\nFix this by saving the index of the corresponding attribute group\n(it might be 1 or 2 depending on the presence of driver-specific\nattributes) and zeroing the pointer to hw_counters group for compat\ndevices during the initialization.\n\nWith this fix applied hw_counters are not available in a non-init\nnet namespace:\n find /sys/class/infiniband/mlx4_0/ -name hw_counters\n /sys/class/infiniband/mlx4_0/ports/1/hw_counters\n /sys/class/infiniband/mlx4_0/ports/2/hw_counters\n /sys/class/infiniband/mlx4_0/hw_counters\n\n ip netns add foo\n ip netns exec foo bash\n find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: unregister xdp rxq info in the reset path\n\nvmxnet3 does not unregister xdp rxq info in the\nvmxnet3_reset_work() code path as vmxnet3_rq_destroy()\nis not invoked in this code path. So, we get below message with a\nbacktrace.\n\nMissing unregister, handled but fix driver\nWARNING: CPU:48 PID: 500 at net/core/xdp.c:182\n__xdp_rxq_info_reg+0x93/0xf0\n\nThis patch fixes the problem by moving the unregister\ncode of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ppp: Add bound checking for skb data on ppp_sync_txmung\n\nEnsure we have enough data in linear buffer from skb before accessing\ninitial bytes. This prevents potential out-of-bounds accesses\nwhen processing short packets.\n\nWhen ppp_sync_txmung receives an incoming package with an empty\npayload:\n(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)\n$18 = {\n\ttype = 0x1,\n\tver = 0x1,\n\tcode = 0x0,\n\tsid = 0x2,\n length = 0x0,\n\ttag = 0xffff8880371cdb96\n}\n\nfrom the skb struct (trimmed)\n tail = 0x16,\n end = 0x140,\n head = 0xffff88803346f400 \u0026quot;4\u0026quot;,\n data = 0xffff88803346f416 \u0026quot;:\\377\u0026quot;,\n truesize = 0x380,\n len = 0x0,\n data_len = 0x0,\n mac_len = 0xe,\n hdr_len = 0x0,\n\nit is not safe to access data[2].\n\n[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: move the limit validation\n\nIt is not sufficient to directly validate the limit on the data that\nthe user passes as it can be updated based on how the other parameters\nare changed.\n\nMove the check at the end of the configuration update process to also\ncatch scenarios where the limit is indirectly updated, for example\nwith the following configurations:\n\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1\n\nThis fixes the following syzkaller reported crash:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6\nindex 65535 is out of range for type \u0026apos;struct sfq_head[128]\u0026apos;\nCPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429\n sfq_link net/sched/sch_sfq.c:203 [inline]\n sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231\n sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493\n sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311\n netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]\n dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix workqueue crash in cma_netevent_work_handler\n\nstruct rdma_cm_id has member \u0026quot;struct work_struct net_work\u0026quot;\nthat is reused for enqueuing cma_netevent_work_handler()s\nonto cma_wq.\n\nBelow crash[1] can occur if more than one call to\ncma_netevent_callback() occurs in quick succession,\nwhich further enqueues cma_netevent_work_handler()s for the\nsame rdma_cm_id, overwriting any previously queued work-item(s)\nthat was just scheduled to run i.e. there is no guarantee\nthe queued work item may run between two successive calls\nto cma_netevent_callback() and the 2nd INIT_WORK would overwrite\nthe 1st work item (for the same rdma_cm_id), despite grabbing\nid_table_lock during enqueue.\n\nAlso drgn analysis [2] indicates the work item was likely overwritten.\n\nFix this by moving the INIT_WORK() to __rdma_create_id(),\nso that it doesn\u0026apos;t race with any existing queue_work() or\nits worker thread.\n\n[1] Trimmed crash stack:\n=============================================\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nkworker/u256:6 ... 6.12.0-0...\nWorkqueue: cma_netevent_work_handler [rdma_cm] (rdma_cm)\nRIP: 0010:process_one_work+0xba/0x31a\nCall Trace:\n worker_thread+0x266/0x3a0\n kthread+0xcf/0x100\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n=============================================\n\n[2] drgn crash analysis:\n\n\u0026gt;\u0026gt;\u0026gt; trace = prog.crashed_thread().stack_trace()\n\u0026gt;\u0026gt;\u0026gt; trace\n(0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)\n(1) __crash_kexec (kernel/crash_core.c:122:4)\n(2) panic (kernel/panic.c:399:3)\n(3) oops_end (arch/x86/kernel/dumpstack.c:382:3)\n...\n(8) process_one_work (kernel/workqueue.c:3168:2)\n(9) process_scheduled_works (kernel/workqueue.c:3310:3)\n(10) worker_thread (kernel/workqueue.c:3391:4)\n(11) kthread (kernel/kthread.c:389:9)\n\nLine workqueue.c:3168 for this kernel version is in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;work\u0026quot;]\n*(struct work_struct *)0xffff92577d0a21d8 = {\n\t.data = (atomic_long_t){\n\t\t.counter = (s64)536870912, \u0026lt;=== Note\n\t},\n\t.entry = (struct list_head){\n\t\t.next = (struct list_head *)0xffff924d075924c0,\n\t\t.prev = (struct list_head *)0xffff924d075924c0,\n\t},\n\t.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,\n}\n\nSuspicion is that pwq is NULL:\n\u0026gt;\u0026gt;\u0026gt; trace[8][\u0026quot;pwq\u0026quot;]\n(struct pool_workqueue *)\u0026lt;absent\u0026gt;\n\nIn process_one_work(), pwq is assigned from:\nstruct pool_workqueue *pwq = get_work_pwq(work);\n\nand get_work_pwq() is:\nstatic struct pool_workqueue *get_work_pwq(struct work_struct *work)\n{\n \tunsigned long data = atomic_long_read(\u0026amp;work-\u0026gt;data);\n\n \tif (data \u0026amp; WORK_STRUCT_PWQ)\n \t\treturn work_struct_pwq(data);\n \telse\n \t\treturn NULL;\n}\n\nWORK_STRUCT_PWQ is 0x4:\n\u0026gt;\u0026gt;\u0026gt; print(repr(prog[\u0026apos;WORK_STRUCT_PWQ\u0026apos;]))\nObject(prog, \u0026apos;enum work_flags\u0026apos;, value=4)\n\nBut work-\u0026gt;data is 536870912 which is 0x20000000.\nSo, get_work_pwq() returns NULL and we crash in process_one_work():\n3168\tstrscpy(worker-\u0026gt;desc, pwq-\u0026gt;wq-\u0026gt;name, WORKER_DESC_LEN);\n=============================================(CVE-2025-37772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt\u0026apos;s not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Purge vif txq in ieee80211_do_stop()\n\nAfter ieee80211_do_stop() SKB from vif\u0026apos;s txq could still be processed.\nIndeed another concurrent vif schedule_and_wake_txq call could cause\nthose packets to be dequeued (see ieee80211_handle_wake_tx_queue())\nwithout checking the sdata current state.\n\nBecause vif.drv_priv is now cleared in this function, this could lead to\ndriver crash.\n\nFor example in ath12k, ahvif is store in vif.drv_priv. Thus if\nath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif-\u0026gt;ah can be\nNULL, leading the ath12k_warn(ahvif-\u0026gt;ah,...) call in this function to\ntrigger the NULL deref below.\n\n Unable to handle kernel paging request at virtual address dfffffc000000001\n KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n batman_adv: bat0: Interface deactivated: brbh1337\n Mem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n [dfffffc000000001] address between user and kernel address ranges\n Internal error: Oops: 0000000096000004 [#1] SMP\n CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114\n Hardware name: HW (DT)\n pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]\n lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]\n sp : ffffffc086ace450\n x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4\n x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e\n x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0\n x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958\n x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8\n x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03\n x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40\n x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0\n x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001\n x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008\n Call trace:\n ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)\n ieee80211_handle_wake_tx_queue+0x16c/0x260\n ieee80211_queue_skb+0xeec/0x1d20\n ieee80211_tx+0x200/0x2c8\n ieee80211_xmit+0x22c/0x338\n __ieee80211_subif_start_xmit+0x7e8/0xc60\n ieee80211_subif_start_xmit+0xc4/0xee0\n __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0\n ieee80211_subif_start_xmit_8023+0x124/0x488\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n br_dev_queue_push_xmit+0x120/0x4a8\n __br_forward+0xe4/0x2b0\n deliver_clone+0x5c/0xd0\n br_flood+0x398/0x580\n br_dev_xmit+0x454/0x9f8\n dev_hard_start_xmit+0x160/0x5a8\n __dev_queue_xmit+0x6f8/0x3120\n ip6_finish_output2+0xc28/0x1b60\n __ip6_finish_output+0x38c/0x638\n ip6_output+0x1b4/0x338\n ip6_local_out+0x7c/0xa8\n ip6_send_skb+0x7c/0x1b0\n ip6_push_pending_frames+0x94/0xd0\n rawv6_sendmsg+0x1a98/0x2898\n inet_sendmsg+0x94/0xe0\n __sys_sendto+0x1e4/0x308\n __arm64_sys_sendto+0xc4/0x140\n do_el0_svc+0x110/0x280\n el0_svc+0x20/0x60\n el0t_64_sync_handler+0x104/0x138\n el0t_64_sync+0x154/0x158\n\nTo avoid that, empty vif\u0026apos;s txq at ieee80211_do_stop() so no packet could\nbe dequeued after ieee80211_do_stop() (new packets cannot be queued\nbecause SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy-\u0026gt;cpus mask. scpi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.(CVE-2025-37829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don\u0026apos;t try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n page isn\u0026apos;t locked, inject memory failure for the page. \n me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n but fails. Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn\u0026apos;t in lru list.(CVE-2025-37834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: avoid infinite loop to schedule delayed worker\n\nWe noticed the kworker in page_pool_release_retry() was waken\nup repeatedly and infinitely in production because of the\nbuggy driver causing the inflight less than 0 and warning\nus in page_pool_inflight()[1].\n\nSince the inflight value goes negative, it means we should\nnot expect the whole page_pool to get back to work normally.\n\nThis patch mitigates the adverse effect by not rescheduling\nthe kworker when detecting the inflight negative in\npage_pool_release_retry().\n\n[1]\n[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------\n[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages\n...\n[Mon Feb 10 20:36:11 2025] Call Trace:\n[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70\n[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370\n[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0\n[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140\n[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370\n[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40\n[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40\n[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---\nNote: before this patch, the above calltrace would flood the\ndmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigc: fix PTM cycle trigger logic\n\nWriting to clear the PTM status \u0026apos;valid\u0026apos; bit while the PTM cycle is\ntriggered results in unreliable PTM operation. To fix this, clear the\nPTM \u0026apos;trigger\u0026apos; and status after each PTM transaction.\n\nThe issue can be reproduced with the following:\n\n$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m\n\nNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way to\nquickly reproduce the issue.\n\nPHC2SYS exits with:\n\n\u0026quot;ioctl PTP_OFFSET_PRECISE: Connection timed out\u0026quot; when the PTM transaction\n fails\n\nThis patch also fixes a hang in igc_probe() when loading the igc\ndriver in the kdump kernel on systems supporting PTM.\n\nThe igc driver running in the base kernel enables PTM trigger in\nigc_probe(). Therefore the driver is always in PTM trigger mode,\nexcept in brief periods when manually triggering a PTM cycle.\n\nWhen a crash occurs, the NIC is reset while PTM trigger is enabled.\nDue to a hardware problem, the NIC is subsequently in a bad busmaster\nstate and doesn\u0026apos;t handle register reads/writes. When running\nigc_probe() in the kdump kernel, the first register access to a NIC\nregister hangs driver probing and ultimately breaks kdump.\n\nWith this patch, igc has PTM trigger disabled most of the time,\nand the trigger is only enabled for very brief (10 - 100 us) periods\nwhen manually triggering a PTM cycle. Chances that a crash occurs\nduring a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/net: fix improper handling of bogus negative read/write replies\n\nIn p9_client_write() and p9_client_read_once(), if the server\nincorrectly replies with success but a negative write/read count then we\nwould consider written (negative) \u0026lt;= rsize (positive) because both\nvariables were signed.\n\nMake variables unsigned to avoid this problem.\n\nThe reproducer linked below now fails with the following error instead\nof a null pointer deref:\n9pnet: bogus RWRITE count (4294967295 \u0026gt; 3)(CVE-2025-37879)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reset IRTE to host control if *new* route isn\u0026apos;t postable\n\nRestore an IRTE back to host control (remapped or posted MSI mode) if the\n*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of\nthe GSI routing type. Updating the IRTE if and only if the new GSI is an\nMSI results in KVM leaving an IRTE posting to a vCPU.\n\nThe dangling IRTE can result in interrupts being incorrectly delivered to\nthe guest, and in the worst case scenario can result in use-after-free,\ne.g. if the VM is torn down, but the underlying host IRQ isn\u0026apos;t freed.(CVE-2025-37885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: Fix memleak issue when GSO enabled\n\nAlways map the `skb` to the LS descriptor. Previously skb was\nmapped to EXT descriptor when the number of fragments is zero with\nGSO enabled. Mapping the skb to EXT descriptor prevents it from\nbeing freed, leading to a memory leak(CVE-2025-37909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix out-of-bound memcpy() during ethtool -w\n\nWhen retrieving the FW coredump using ethtool, it can sometimes cause\nmemory corruption:\n\nBUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nCorrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):\n__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nethtool_get_dump_data+0xdc/0x1a0\n__dev_ethtool+0xa1e/0x1af0\ndev_ethtool+0xa8/0x170\ndev_ioctl+0x1b5/0x580\nsock_do_ioctl+0xab/0xf0\nsock_ioctl+0x1ce/0x2e0\n__x64_sys_ioctl+0x87/0xc0\ndo_syscall_64+0x5c/0xf0\nentry_SYSCALL_64_after_hwframe+0x78/0x80\n\n...\n\nThis happens when copying the coredump segment list in\nbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.\nThe info-\u0026gt;dest_buf buffer is allocated based on the number of coredump\nsegments returned by the FW. The segment list is then DMA\u0026apos;ed by\nthe FW and the length of the DMA is returned by FW. The driver then\ncopies this DMA\u0026apos;ed segment list to info-\u0026gt;dest_buf.\n\nIn some cases, this DMA length may exceed the info-\u0026gt;dest_buf length\nand cause the above BUG condition. Fix it by capping the copy\nlength to not exceed the length of info-\u0026gt;dest_buf. The extra\nDMA data contains no useful information.\n\nThis code path is shared for the HWRM_DBG_COREDUMP_LIST and the\nHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different\nfor these 2 FW commands. To simplify the logic, we need to move\nthe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE\nup, so that the new check to cap the copy length will work for both\ncommands.(CVE-2025-37911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()\n\nAs mentioned in the commit baeb705fd6a7 (\u0026quot;ice: always check VF VSI\npointer values\u0026quot;), we need to perform a null pointer check on the return\nvalue of ice_get_vf_vsi() before using it.(CVE-2025-37912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: make htb_qlen_notify() idempotent\n\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\n\nLet\u0026apos;s make it idempotent to ease qdisc_tree_reduce_backlog() callers\u0026apos;\nlife.(CVE-2025-37932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY\n\nDSA has 2 kinds of drivers:\n\n1. Those who call dsa_switch_suspend() and dsa_switch_resume() from\n their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz\n2. Those who don\u0026apos;t: all others. The above methods should be optional.\n\nFor type 1, dsa_switch_suspend() calls dsa_user_suspend() -\u0026gt; phylink_stop(),\nand dsa_switch_resume() calls dsa_user_resume() -\u0026gt; phylink_start().\nThese seem good candidates for setting mac_managed_pm = true because\nthat is essentially its definition [1], but that does not seem to be the\nbiggest problem for now, and is not what this change focuses on.\n\nTalking strictly about the 2nd category of DSA drivers here (which\ndo not have MAC managed PM, meaning that for their attached PHYs,\nmdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),\nI have noticed that the following warning from mdio_bus_phy_resume() is\ntriggered:\n\n\tWARN_ON(phydev-\u0026gt;state != PHY_HALTED \u0026amp;\u0026amp; phydev-\u0026gt;state != PHY_READY \u0026amp;\u0026amp;\n\t\tphydev-\u0026gt;state != PHY_UP);\n\nbecause the PHY state machine is running.\n\nIt\u0026apos;s running as a result of a previous dsa_user_open() -\u0026gt; ... -\u0026gt;\nphylink_start() -\u0026gt; phy_start() having been initiated by the user.\n\nThe previous mdio_bus_phy_suspend() was supposed to have called\nphy_stop_machine(), but it didn\u0026apos;t. So this is why the PHY is in state\nPHY_NOLINK by the time mdio_bus_phy_resume() runs.\n\nmdio_bus_phy_suspend() did not call phy_stop_machine() because for\nphylink, the phydev-\u0026gt;adjust_link function pointer is NULL. This seems a\ntechnicality introduced by commit fddd91016d16 (\u0026quot;phylib: fix PAL state\nmachine restart on resume\u0026quot;). That commit was written before phylink\nexisted, and was intended to avoid crashing with consumer drivers which\ndon\u0026apos;t use the PHY state machine - phylink always does, when using a PHY.\nBut phylink itself has historically not been developed with\nsuspend/resume in mind, and apparently not tested too much in that\nscenario, allowing this bug to exist unnoticed for so long. Plus, prior\nto the WARN_ON(), it would have likely been invisible.\n\nThis issue is not in fact restricted to type 2 DSA drivers (according to\nthe above ad-hoc classification), but can be extrapolated to any MAC\ndriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where\nthe issue was reported. Assuming mac_managed_pm is set correctly, a\nquick search indicates the following other drivers might be affected:\n\n$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm\ndrivers/net/ethernet/atheros/ag71xx.c\ndrivers/net/ethernet/microchip/sparx5/sparx5_main.c\ndrivers/net/ethernet/microchip/lan966x/lan966x_main.c\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c\ndrivers/net/ethernet/freescale/fs_enet/fs_enet-main.c\ndrivers/net/ethernet/freescale/dpaa/dpaa_eth.c\ndrivers/net/ethernet/freescale/ucc_geth.c\ndrivers/net/ethernet/freescale/enetc/enetc_pf_common.c\ndrivers/net/ethernet/marvell/mvpp2/mvpp2_main.c\ndrivers/net/ethernet/marvell/mvneta.c\ndrivers/net/ethernet/marvell/prestera/prestera_main.c\ndrivers/net/ethernet/mediatek/mtk_eth_soc.c\ndrivers/net/ethernet/altera/altera_tse_main.c\ndrivers/net/ethernet/wangxun/txgbe/txgbe_phy.c\ndrivers/net/ethernet/meta/fbnic/fbnic_phylink.c\ndrivers/net/ethernet/tehuti/tn40_phy.c\ndrivers/net/ethernet/mscc/ocelot_net.c\n\nMake the existing conditions dependent on the PHY device having a\nphydev-\u0026gt;phy_link_change() implementation equal to the default\nphy_link_change() provided by phylib. Otherwise, we implicitly know that\nthe phydev has the phylink-provided phylink_phy_change() callback, and\nwhen phylink is used, the PHY state machine always needs to be stopped/\nstarted on the suspend/resume path. The code is structured as such that\nif phydev-\u0026gt;phy_link_change() is absent, it is a matter of time until the\nkernel will crash - no need to further complicate the test.\n\nThus, for the situation where the PM is not managed b\n---truncated---(CVE-2025-37945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn\u0026apos;t scrubbed. That can lead skb\ninformation from one namespace to be \u0026quot;misused\u0026quot; in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host\u0026apos;s XFRM layer to the container\u0026apos;s XFRM\nlayer where it\u0026apos;s dropped and (2) the number of active skb extensions at\neach function.\n\n NETNS MARK IFACE TUPLE FUNC\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 xfrm4_rcv_cb\n .active_extensions = (__u8)2,\n 4026533547 d00 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 gro_cells_receive\n .active_extensions = (__u8)2,\n [...]\n 4026533547 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 skb_do_redirect\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 ip_rcv_core\n .active_extensions = (__u8)2,\n [...]\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 udp_queue_rcv_one_skb\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_policy_check\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 __xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 security_xfrm_decode_session\n .active_extensions = (__u8)2,\n 4026534999 0 eth0 10.244.3.124:35473-\u0026gt;10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container\u0026apos;s network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container\u0026apos;s netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can\u0026apos;t be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb-\u0026gt;mark and skb-\u0026gt;tstamp are not zeroed.(CVE-2025-37959)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemblock: Accept allocated memory before use in memblock_double_array()\n\nWhen increasing the array size in memblock_double_array() and the slab\nis not yet available, a call to memblock_find_in_range() is used to\nreserve/allocate memory. However, the range returned may not have been\naccepted, which can result in a crash when booting an SNP guest:\n\n RIP: 0010:memcpy_orig+0x68/0x130\n Code: ...\n RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006\n RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000\n RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00\n RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000\n R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78\n R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00\n memblock_double_array+0xff/0x310\n memblock_add_range+0x1fb/0x2f0\n memblock_reserve+0x4f/0xa0\n memblock_alloc_range_nid+0xac/0x130\n memblock_alloc_internal+0x53/0xc0\n memblock_alloc_try_nid+0x3d/0xa0\n swiotlb_init_remap+0x149/0x2f0\n mem_init+0xb/0xb0\n mm_core_init+0x8f/0x350\n start_kernel+0x17e/0x5d0\n x86_64_start_reservations+0x14/0x30\n x86_64_start_kernel+0x92/0xa0\n secondary_startup_64_no_verify+0x194/0x19b\n\nMitigate this by calling accept_memory() on the memory range returned\nbefore the slab is available.\n\nPrior to v6.12, the accept_memory() interface used a \u0026apos;start\u0026apos; and \u0026apos;end\u0026apos;\nparameter instead of \u0026apos;start\u0026apos; and \u0026apos;size\u0026apos;, therefore the accept_memory()\ncall must be adjusted to specify \u0026apos;start + size\u0026apos; for \u0026apos;end\u0026apos; when applying\nto kernels prior to v6.12.(CVE-2025-37960)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix uninit-value for saddr in do_output_route4\n\nsyzbot reports for uninit-value for the saddr argument [1].\ncommit 4754957f04f5 (\u0026quot;ipvs: do not use random local source address for\ntunnels\u0026quot;) already implies that the input value of saddr\nshould be ignored but the code is still reading it which can prevent\nto connect the route. Fix it by changing the argument to ret_saddr.\n\n[1]\nBUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4167 [inline]\n slab_alloc_node mm/slub.c:4210 [inline]\n __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367\n kmalloc_noprof include/linux/slab.h:905 [inline]\n ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]\n __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)\nHardware name: Google Google Compute Engi\n---truncated---(CVE-2025-37961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: leds: fix memory leak\n\nA network restart test on a router led to an out-of-memory condition,\nwhich was traced to a memory leak in the PHY LED trigger code.\n\nThe root cause is misuse of the devm API. The registration function\n(phy_led_triggers_register) is called from phy_attach_direct, not\nphy_probe, and the unregister function (phy_led_triggers_unregister)\nis called from phy_detach, not phy_remove. This means the register and\nunregister functions can be called multiple times for the same PHY\ndevice, but devm-allocated memory is not freed until the driver is\nunbound.\n\nThis also prevents kmemleak from detecting the leak, as the devm API\ninternally stores the allocated pointer.\n\nFix this by replacing devm_kzalloc/devm_kcalloc with standard\nkzalloc/kcalloc, and add the corresponding kfree calls in the unregister\npath.(CVE-2025-37989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()\n\nThe function brcmf_usb_dl_writeimage() calls the function\nbrcmf_usb_dl_cmd() but dose not check its return value. The\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized if the\nfunction brcmf_usb_dl_cmd() fails. It is dangerous to use\nuninitialized variables in the conditions.\n\nAdd error handling for brcmf_usb_dl_cmd() to jump to error\nhandling path if the brcmf_usb_dl_cmd() fails and the\n\u0026apos;state.state\u0026apos; and the \u0026apos;state.bytes\u0026apos; are uninitialized.\n\nImprove the error message to report more detailed error\ninformation.(CVE-2025-37990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add missing rcu read protection for procfs content\n\nWhen the procfs content is generated for a bcm_op which is in the process\nto be removed the procfs output might show unreliable data (UAF).\n\nAs the removal of bcm_op\u0026apos;s is already implemented with rcu handling this\npatch adds the missing rcu_read_lock() and makes sure the list entries\nare properly removed under rcu protection.(CVE-2025-38003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add locking for bcm_op runtime updates\n\nThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via\nhrtimer. The content and also the length of the sequence can be changed\nresp reduced at runtime where the \u0026apos;currframe\u0026apos; counter is then set to zero.\n\nAlthough this appeared to be a safe operation the updates of \u0026apos;currframe\u0026apos;\ncan be triggered from user space and hrtimer context in bcm_can_tx().\nAnderson Nascimento created a proof of concept that triggered a KASAN\nslab-out-of-bounds read access which can be prevented with a spin_lock_bh.\n\nAt the rework of bcm_can_tx() the \u0026apos;count\u0026apos; variable has been moved into\nthe protected section as this variable can be modified from both contexts\ntoo.(CVE-2025-38004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: tegra: xusb: Use a bitmask for UTMI pad power state tracking\n\nThe current implementation uses bias_pad_enable as a reference count to\nmanage the shared bias pad for all UTMI PHYs. However, during system\nsuspension with connected USB devices, multiple power-down requests for\nthe UTMI pad result in a mismatch in the reference count, which in turn\nproduces warnings such as:\n\n[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763103] Call trace:\n[ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170\n[ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30\n[ 237.763110] phy_power_off+0x48/0x100\n[ 237.763113] tegra_xusb_enter_elpg+0x204/0x500\n[ 237.763119] tegra_xusb_suspend+0x48/0x140\n[ 237.763122] platform_pm_suspend+0x2c/0xb0\n[ 237.763125] dpm_run_callback.isra.0+0x20/0xa0\n[ 237.763127] __device_suspend+0x118/0x330\n[ 237.763129] dpm_suspend+0x10c/0x1f0\n[ 237.763130] dpm_suspend_start+0x88/0xb0\n[ 237.763132] suspend_devices_and_enter+0x120/0x500\n[ 237.763135] pm_suspend+0x1ec/0x270\n\nThe root cause was traced back to the dynamic power-down changes\nintroduced in commit a30951d31b25 (\u0026quot;xhci: tegra: USB2 pad power controls\u0026quot;),\nwhere the UTMI pad was being powered down without verifying its current\nstate. This unbalanced behavior led to discrepancies in the reference\ncount.\n\nTo rectify this issue, this patch replaces the single reference counter\nwith a bitmask, renamed to utmi_pad_enabled. Each bit in the mask\ncorresponds to one of the four USB2 PHYs, allowing us to track each pad\u0026apos;s\nenablement status individually.\n\nWith this change:\n - The bias pad is powered on only when the mask is clear.\n - Each UTMI pad is powered on or down based on its corresponding bit\n in the mask, preventing redundant operations.\n - The overall power state of the shared bias pad is maintained\n correctly during suspend/resume cycles.\n\nThe mutex used to prevent race conditions during UTMI pad enable/disable\noperations has been moved from the tegra186_utmi_bias_pad_power_on/off\nfunctions to the parent functions tegra186_utmi_pad_power_on/down. This\nchange ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices\n\nThe driver only offloads neighbors that are constructed on top of net\ndevices registered by it or their uppers (which are all Ethernet). The\ndevice supports GRE encapsulation and decapsulation of forwarded\ntraffic, but the driver will not offload dummy neighbors constructed on\ntop of GRE net devices as they are not uppers of its net devices:\n\n # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1\n # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 NOARP\n\n(Note that the neighbor is not marked with \u0026apos;offload\u0026apos;)\n\nWhen the driver is reloaded and the existing configuration is replayed,\nthe driver does not perform the same check regarding existing neighbors\nand offloads the previously added one:\n\n # devlink dev reload pci/0000:01:00.0\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 offload NOARP\n\nIf the neighbor is later deleted, the driver will ignore the\nnotification (given the GRE net device is not its upper) and will\ntherefore keep referencing freed memory, resulting in a use-after-free\n[1] when the net device is deleted:\n\n # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1\n # ip link del dev gre1\n\nFix by skipping neighbor replay if the net device for which the replay\nis performed is not our upper.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200\nRead of size 8 at addr ffff888155b0e420 by task ip/2282\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6f/0x350\n print_report+0x108/0x205\n kasan_report+0xdf/0x110\n mlxsw_sp_neigh_entry_update+0x1ea/0x200\n mlxsw_sp_router_rif_gone_sync+0x2a8/0x440\n mlxsw_sp_rif_destroy+0x1e9/0x750\n mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0\n mlxsw_sp_router_netdevice_event+0x3ac/0x15e0\n notifier_call_chain+0xca/0x150\n call_netdevice_notifiers_info+0x7f/0x100\n unregister_netdevice_many_notify+0xc8c/0x1d90\n rtnl_dellink+0x34e/0xa50\n rtnetlink_rcv_msg+0x6fb/0xb70\n netlink_rcv_skb+0x131/0x360\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Disable MACsec offload for uplink representor profile\n\nMACsec offload is not supported in switchdev mode for uplink\nrepresentors. When switching to the uplink representor profile, the\nMACsec offload feature must be cleared from the netdevice\u0026apos;s features.\n\nIf left enabled, attempts to add offloads result in a null pointer\ndereference, as the uplink representor does not support MACsec offload\neven though the feature bit remains set.\n\nClear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().\n\nKernel log:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]\nCPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__mutex_lock+0x128/0x1dd0\nCode: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff\nRSP: 0018:ffff888147a4f160 EFLAGS: 00010206\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078\nRBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000\nFS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x3d/0xa0\n ? exc_general_protection+0x144/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? __mutex_lock+0x128/0x1dd0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mutex_lock_io_nested+0x1ae0/0x1ae0\n ? lock_acquire+0x1c2/0x530\n ? macsec_upd_offload+0x145/0x380\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n ? __kasan_kmalloc+0x77/0x90\n ? __kmalloc_noprof+0x249/0x6b0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]\n macsec_update_offload+0x26c/0x820\n ? macsec_set_mac_address+0x4b0/0x4b0\n ? lockdep_hardirqs_on_prepare+0x284/0x400\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n macsec_upd_offload+0x2c8/0x380\n ? macsec_update_offload+0x820/0x820\n ? __nla_parse+0x22/0x30\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240\n genl_family_rcv_msg_doit+0x1cc/0x2a0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240\n ? cap_capable+0xd4/0x330\n genl_rcv_msg+0x3ea/0x670\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? macsec_update_offload+0x820/0x820\n netlink_rcv_skb+0x12b/0x390\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? netlink_ack+0xd80/0xd80\n ? rwsem_down_read_slowpath+0xf90/0xf90\n ? netlink_deliver_tap+0xcd/0xac0\n ? netlink_deliver_tap+0x155/0xac0\n ? _copy_from_iter+0x1bb/0x12c0\n genl_rcv+0x24/0x40\n netlink_unicast+0x440/0x700\n ? netlink_attachskb+0x760/0x760\n ? lock_acquire+0x1c2/0x530\n ? __might_fault+0xbb/0x170\n netlink_sendmsg+0x749/0xc10\n ? netlink_unicast+0x700/0x700\n ? __might_fault+0xbb/0x170\n ? netlink_unicast+0x700/0x700\n __sock_sendmsg+0xc5/0x190\n ____sys_sendmsg+0x53f/0x760\n ? import_iovec+0x7/0x10\n ? kernel_sendmsg+0x30/0x30\n ? __copy_msghdr+0x3c0/0x3c0\n ? filter_irq_stacks+0x90/0x90\n ? stack_depot_save_flags+0x28/0xa30\n ___sys_sen\n---truncated---(CVE-2025-38020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix \u0026quot;KASAN: slab-use-after-free Read in ib_register_device\u0026quot; problem\n\nCall Trace:\n\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n strlen+0x93/0xa0 lib/string.c:420\n __fortify_strlen include/linux/fortify-string.h:268 [inline]\n get_kobj_path_length lib/kobject.c:118 [inline]\n kobject_get_path+0x3f/0x2a0 lib/kobject.c:158\n kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545\n ib_register_device drivers/infiniband/core/device.c:1472 [inline]\n ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393\n rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552\n rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225\n nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796\n rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195\n rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmsg+0x16d/0x220 net/socket.c:2652\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThis problem is similar to the problem that the\ncommit 1d6a9e7449e2 (\u0026quot;RDMA/core: Fix use-after-free when rename device name\u0026quot;)\nfixes.\n\nThe root cause is: the function ib_device_rename() renames the name with\nlock. But in the function kobject_uevent(), this name is accessed without\nlock protection at the same time.\n\nThe solution is to add the lock protection when this name is accessed in\nthe function kobject_uevent().(CVE-2025-38022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.(CVE-2025-38024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled\n\nWhen attempting to enable MQPRIO while HTB offload is already\nconfigured, the driver currently returns `-EINVAL` and triggers a\n`WARN_ON`, leading to an unnecessary call trace.\n\nUpdate the code to handle this case more gracefully by returning\n`-EOPNOTSUPP` instead, while also providing a helpful user message.(CVE-2025-38039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn\n\nThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can\nrun on multiple platforms having different DMA architectures.\nOn some platforms there can be one FDQ for all flows in the RX channel\nwhile for others there is a separate FDQ for each flow in the RX channel.\n\nSo far we have been relying on the skip_fdq argument of\nk3_udma_glue_reset_rx_chn().\n\nInstead of relying on the user to provide this information, infer it\nbased on DMA architecture during k3_udma_glue_request_rx_chn() and save it\nin an internal flag \u0026apos;single_fdq\u0026apos;. Use that flag at\nk3_udma_glue_reset_rx_chn() to deicide if the FDQ needs\nto be cleared for every flow or just for flow 0.\n\nFixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.\n\n\u0026gt; ip link set eth1 down\n\u0026gt; ip link set eth0 down\n\u0026gt; ethtool -L eth0 rx 8\n\u0026gt; ip link set eth0 up\n\u0026gt; modprobe -r ti_am65_cpsw_nuss\n\n[ 103.045726] ------------[ cut here ]------------\n[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000\n[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas\np drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r\nfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool]\n[ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011\n[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)\n[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[ 103.154709] sp : ffff8000826ebbc0\n[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000\n[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0\n[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88\n[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000\n[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde\n[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000\n[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20\n[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100\n[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000\n[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000\n[ 103.229274] Call trace:\n[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)\n[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss]\n[ 103.244942] devm_action_release+0x14/0x20\n[ 103.249040] release_nodes+0x3c/0x68\n[ 103.252610] devres_release_all+0x8c/0xdc\n[ 103.256614] device_unbind_cleanup+0x18/0x60\n[ 103.260876] device_release_driver_internal+0xf8/0x178\n[ 103.266004] driver_detach+0x50/0x9c\n[ 103.269571] bus_remove_driver+0x6c/0xbc\n[ 103.273485] driver_unregister+0x30/0x60\n[ 103.277401] platform_driver_unregister+0x14/0x20\n[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss]\n[ 103.288620] __arm64_sys_delete_module+0x17c/0x25c\n[ 103.293404] invoke_syscall+0x44/0x100\n[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0\n[ 103.301845] do_el0_svc+0x1c/0x28\n[ 103.305155] el0_svc+0x28/0x98\n---truncated---(CVE-2025-38042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: set device_caps for 417\n\nThe video_device for the MPEG encoder did not set device_caps.\n\nAdd this, otherwise the video device can\u0026apos;t be registered (you get a\nWARN_ON instead).\n\nNot seen before since currently 417 support is disabled, but I found\nthis while experimenting with it.(CVE-2025-38044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: fix skb leaks\n\nA few error paths are missing a kfree_skb.(CVE-2025-38057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: prevent BUG_ON by blocking retries on failed device resumes\n\nA cache device failing to resume due to mapping errors should not be\nretried, as the failure leaves a partially initialized policy object.\nRepeating the resume operation risks triggering BUG_ON when reloading\ncache mappings into the incomplete policy object.\n\nReproduce steps:\n\n1. create a cache metadata consisting of 512 or more cache blocks,\n with some mappings stored in the first array block of the mapping\n array. Here we use cache_restore v1.0 to build the metadata.\n\ncat \u0026lt;\u0026lt;EOF \u0026gt;\u0026gt; cmeta.xml\n\u0026lt;superblock uuid=\u0026quot;\u0026quot; block_size=\u0026quot;128\u0026quot; nr_cache_blocks=\u0026quot;512\u0026quot; \\\npolicy=\u0026quot;smq\u0026quot; hint_width=\u0026quot;4\u0026quot;\u0026gt;\n \u0026lt;mappings\u0026gt;\n \u0026lt;mapping cache_block=\u0026quot;0\u0026quot; origin_block=\u0026quot;0\u0026quot; dirty=\u0026quot;false\u0026quot;/\u0026gt;\n \u0026lt;/mappings\u0026gt;\n\u0026lt;/superblock\u0026gt;\nEOF\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ncache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2\ndmsetup remove cmeta\n\n2. wipe the second array block of the mapping array to simulate\n data degradations.\n\nmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\nablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\ndd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock\n\n3. try bringing up the cache device. The resume is expected to fail\n due to the broken array block.\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndmsetup create cache --notable\ndmsetup load cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\ndmsetup resume cache\n\n4. try resuming the cache again. An unexpected BUG_ON is triggered\n while loading cache mappings.\n\ndmsetup resume cache\n\nKernel logs:\n\n(snip)\n------------[ cut here ]------------\nkernel BUG at drivers/md/dm-cache-policy-smq.c:752!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3\nRIP: 0010:smq_load_mapping+0x3e5/0x570\n\nFix by disallowing resume operations for devices that failed the\ninitial attempt.(CVE-2025-38066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race\n\nhuge_pmd_unshare() drops a reference on a page table that may have\npreviously been shared across processes, potentially turning it into a\nnormal page table used in another process in which unrelated VMAs can\nafterwards be installed.\n\nIf this happens in the middle of a concurrent gup_fast(), gup_fast() could\nend up walking the page tables of another process. While I don\u0026apos;t see any\nway in which that immediately leads to kernel memory corruption, it is\nreally weird and unexpected.\n\nFix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),\njust like we do in khugepaged when removing page tables for a THP\ncollapse.(CVE-2025-38085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix use-after-free in taprio_dev_notifier\n\nSince taprio\u2019s taprio_dev_notifier() isn\u2019t protected by an\nRCU read-side critical section, a race with advance_sched()\ncan lead to a use-after-free.\n\nAdding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: remove encap socket caching to avoid reference leak\n\nThe current scheme for caching the encap socket can lead to reference\nleaks when we try to delete the netns.\n\nThe reference chain is: xfrm_state -\u0026gt; enacp_sk -\u0026gt; netns\n\nSince the encap socket is a userspace socket, it holds a reference on\nthe netns. If we delete the espintcp state (through flush or\nindividual delete) before removing the netns, the reference on the\nsocket is dropped and the netns is correctly deleted. Otherwise, the\nnetns may not be reachable anymore (if all processes within the ns\nhave terminated), so we cannot delete the xfrm state to drop its\nreference on the socket.\n\nThis patch results in a small (~2% in my tests) performance\nregression.\n\nA GC-type mechanism could be added for the socket cache, to clear\nreferences if the state hasn\u0026apos;t been used \u0026quot;recently\u0026quot;, but it\u0026apos;s a lot\nmore complex than just not caching the socket.(CVE-2025-38097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: Fix use-after-free in page_pool_recycle_in_ring\n\nsyzbot reported a uaf in page_pool_recycle_in_ring:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\nRead of size 8 at addr ffff8880286045a0 by task syz.0.284/6943\n\nCPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]\n _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]\n page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]\n page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826\n page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]\n page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]\n napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036\n skb_pp_recycle net/core/skbuff.c:1047 [inline]\n skb_free_head net/core/skbuff.c:1094 [inline]\n skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125\n skb_release_all net/core/skbuff.c:1190 [inline]\n __kfree_skb net/core/skbuff.c:1204 [inline]\n sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242\n kfree_skb_reason include/linux/skbuff.h:1263 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]\n\nroot cause is:\n\npage_pool_recycle_in_ring\n ptr_ring_produce\n spin_lock(\u0026amp;r-\u0026gt;producer_lock);\n WRITE_ONCE(r-\u0026gt;queue[r-\u0026gt;producer++], ptr)\n //recycle last page to pool\n\t\t\t\tpage_pool_release\n\t\t\t\t page_pool_scrub\n\t\t\t\t page_pool_empty_ring\n\t\t\t\t ptr_ring_consume\n\t\t\t\t page_pool_return_page //release all page\n\t\t\t\t __page_pool_destroy\n\t\t\t\t free_percpu(pool-\u0026gt;recycle_stats);\n\t\t\t\t free(pool) //free\n\n spin_unlock(\u0026amp;r-\u0026gt;producer_lock); //pool-\u0026gt;ring uaf read\n recycle_stat_inc(pool, ring);\n\npage_pool can be free while page pool recycle the last page in ring.\nAdd producer-lock barrier to page_pool_release to prevent the page\npool from being free before all pages have been recycled.\n\nrecycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not\nenabled, which will trigger Wempty-body build warning. Add definition\nfor pool stat macro to fix warning.(CVE-2025-38129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u0026gt;sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0026apos;\u0026apos;\u0026apos;\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u0026gt;release() -\u0026gt; sock_map_close()\n sk_socket-\u0026gt;ops = NULL\n free(socket)\n sock-\u0026gt;ops-\u0026gt;sendmsg\n ^\n panic here\n\u0026apos;\u0026apos;\u0026apos;\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0026apos;\u0026apos;\u0026apos;\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u0026lt;=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0026apos;\u0026apos;\u0026apos;\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0026apos;t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0026apos;\u0026apos;\u0026apos;\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0026apos;\u0026apos;\u0026apos;(CVE-2025-38154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix panic when calling skb_linearize\n\nThe panic can be reproduced by executing the command:\n./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000\n\nThen a kernel panic was captured:\n\u0026apos;\u0026apos;\u0026apos;\n[ 657.460555] kernel BUG at net/core/skbuff.c:2178!\n[ 657.462680] Tainted: [W]=WARN\n[ 657.463287] Workqueue: events sk_psock_backlog\n...\n[ 657.469610] \u0026lt;TASK\u0026gt;\n[ 657.469738] ? die+0x36/0x90\n[ 657.469916] ? do_trap+0x1d0/0x270\n[ 657.470118] ? pskb_expand_head+0x612/0xf40\n[ 657.470376] ? pskb_expand_head+0x612/0xf40\n[ 657.470620] ? do_error_trap+0xa3/0x170\n[ 657.470846] ? pskb_expand_head+0x612/0xf40\n[ 657.471092] ? handle_invalid_op+0x2c/0x40\n[ 657.471335] ? pskb_expand_head+0x612/0xf40\n[ 657.471579] ? exc_invalid_op+0x2d/0x40\n[ 657.471805] ? asm_exc_invalid_op+0x1a/0x20\n[ 657.472052] ? pskb_expand_head+0xd1/0xf40\n[ 657.472292] ? pskb_expand_head+0x612/0xf40\n[ 657.472540] ? lock_acquire+0x18f/0x4e0\n[ 657.472766] ? find_held_lock+0x2d/0x110\n[ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10\n[ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470\n[ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10\n[ 657.473826] __pskb_pull_tail+0xfd/0x1d20\n[ 657.474062] ? __kasan_slab_alloc+0x4e/0x90\n[ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510\n[ 657.475392] ? __kasan_kmalloc+0xaa/0xb0\n[ 657.476010] sk_psock_backlog+0x5cf/0xd70\n[ 657.476637] process_one_work+0x858/0x1a20\n\u0026apos;\u0026apos;\u0026apos;\n\nThe panic originates from the assertion BUG_ON(skb_shared(skb)) in\nskb_linearize(). A previous commit(see Fixes tag) introduced skb_get()\nto avoid race conditions between skb operations in the backlog and skb\nrelease in the recvmsg path. However, this caused the panic to always\noccur when skb_linearize is executed.\n\nThe \u0026quot;--rx-strp 100000\u0026quot; parameter forces the RX path to use the strparser\nmodule which aggregates data until it reaches 100KB before calling sockmap\nlogic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.\n\nTo fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.\n\n\u0026apos;\u0026apos;\u0026apos;\nsk_psock_backlog:\n sk_psock_handle_skb\n skb_get(skb) \u0026lt;== we move it into \u0026apos;sk_psock_skb_ingress_enqueue\u0026apos;\n sk_psock_skb_ingress____________\n \u2193\n |\n | \u2192 sk_psock_skb_ingress_self\n | sk_psock_skb_ingress_enqueue\nsk_psock_verdict_apply_________________\u2191 skb_linearize\n\u0026apos;\u0026apos;\u0026apos;\n\nNote that for verdict_apply path, the skb_get operation is unnecessary so\nwe add \u0026apos;take_ref\u0026apos; param to control it\u0026apos;s behavior.(CVE-2025-38165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix ktls panic with sockmap\n\n[ 2172.936997] ------------[ cut here ]------------\n[ 2172.936999] kernel BUG at lib/iov_iter.c:629!\n......\n[ 2172.944996] PKRU: 55555554\n[ 2172.945155] Call Trace:\n[ 2172.945299] \u0026lt;TASK\u0026gt;\n[ 2172.945428] ? die+0x36/0x90\n[ 2172.945601] ? do_trap+0xdd/0x100\n[ 2172.945795] ? iov_iter_revert+0x178/0x180\n[ 2172.946031] ? iov_iter_revert+0x178/0x180\n[ 2172.946267] ? do_error_trap+0x7d/0x110\n[ 2172.946499] ? iov_iter_revert+0x178/0x180\n[ 2172.946736] ? exc_invalid_op+0x50/0x70\n[ 2172.946961] ? iov_iter_revert+0x178/0x180\n[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20\n[ 2172.947446] ? iov_iter_revert+0x178/0x180\n[ 2172.947683] ? iov_iter_revert+0x5c/0x180\n[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840\n[ 2172.948206] tls_sw_sendmsg+0x52/0x80\n[ 2172.948420] ? inet_sendmsg+0x1f/0x70\n[ 2172.948634] __sys_sendto+0x1cd/0x200\n[ 2172.948848] ? find_held_lock+0x2b/0x80\n[ 2172.949072] ? syscall_trace_enter+0x140/0x270\n[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170\n[ 2172.949595] ? find_held_lock+0x2b/0x80\n[ 2172.949817] ? syscall_trace_enter+0x140/0x270\n[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190\n[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0\n[ 2172.951036] __x64_sys_sendto+0x24/0x30\n[ 2172.951382] do_syscall_64+0x90/0x170\n......\n\nAfter calling bpf_exec_tx_verdict(), the size of msg_pl-\u0026gt;sg may increase,\ne.g., when the BPF program executes bpf_msg_push_data().\n\nIf the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,\nit will return -ENOSPC and attempt to roll back to the non-zero copy\nlogic. However, during rollback, msg-\u0026gt;msg_iter is reset, but since\nmsg_pl-\u0026gt;sg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n\u0026apos;\u0026apos;\u0026apos;\niov_iter_revert(\u0026amp;msg-\u0026gt;msg_iter, msg_pl-\u0026gt;sg.size - orig_size);\n\u0026apos;\u0026apos;\u0026apos;\n\nThe changes in this commit are based on the following considerations:\n\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n\n2. We can not calculate the correct number of bytes to revert msg_iter.\n\nAssume the original data is \u0026quot;abcdefgh\u0026quot; (8 bytes), and after 3 pushes\nby the BPF program, it becomes 11-byte data: \u0026quot;abc?de?fgh?\u0026quot;.\nThen, we set cork_bytes to 6, which means the first 6 bytes have been\nprocessed, and the remaining 5 bytes \u0026quot;?fgh?\u0026quot; will be cached until the\nlength meets the cork_bytes requirement.\n\nHowever, some data in \u0026quot;?fgh?\u0026quot; is not within \u0026apos;sg-\u0026gt;msg_iter\u0026apos;\n(but in msg_pl instead), especially the data \u0026quot;?\u0026quot; we pushed.\n\nSo it doesn\u0026apos;t seem as simple as just reverting through an offset of\nmsg_iter.\n\n3. For non-TLS sockets in tcp_bpf_sendmsg, when a \u0026quot;cork\u0026quot; situation occurs,\nthe user-space send() doesn\u0026apos;t return an error, and the returned length is\nthe same as the input length parameter, even if some data is cached.\n\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n\u0026apos;\u0026apos;\u0026apos;\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n\u0026apos;\u0026apos;\u0026apos;\n\nSo it\u0026apos;s ok to just return \u0026apos;copied\u0026apos; without error when a \u0026quot;cork\u0026quot; situation\noccurs.(CVE-2025-38166)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: make hfsc_qlen_notify() idempotent\n\nhfsc_qlen_notify() is not idempotent either and not friendly\nto its callers, like fq_codel_dequeue(). Let\u0026apos;s make it idempotent\nto ease qdisc_tree_reduce_backlog() callers\u0026apos; life:\n\n1. update_vf() decreases cl-\u0026gt;cl_nactive, so we can check whether it is\nnon-zero before calling it.\n\n2. eltree_remove() always removes RB node cl-\u0026gt;el_node, but we can use\n RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush\n\nIn KVM guests with Hyper-V hypercalls enabled, the hypercalls\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX\nallow a guest to request invalidation of portions of a virtual TLB.\nFor this, the hypercall parameter includes a list of GVAs that are supposed\nto be invalidated.\n\nHowever, when non-canonical GVAs are passed, there is currently no\nfiltering in place and they are eventually passed to checked invocations of\nINVVPID on Intel / INVLPGA on AMD. While AMD\u0026apos;s INVLPGA silently ignores\nnon-canonical addresses (effectively a no-op), Intel\u0026apos;s INVVPID explicitly\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():\n\n invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000\n WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482\n invvpid_error+0x91/0xa0 [kvm_intel]\n Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse\n CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)\n RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]\n Call Trace:\n vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]\n kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]\n\nHyper-V documents that invalid GVAs (those that are beyond a partition\u0026apos;s\nGVA space) are to be ignored. While not completely clear whether this\nruling also applies to non-canonical GVAs, it is likely fine to make that\nassumption, and manual testing on Azure confirms \u0026quot;real\u0026quot; Hyper-V interprets\nthe specification in the same way.\n\nSkip non-canonical GVAs when processing the list of address to avoid\ntripping the INVVPID failure. Alternatively, KVM could filter out \u0026quot;bad\u0026quot;\nGVAs before inserting into the FIFO, but practically speaking the only\ndownside of pushing validation to the final processing is that doing so\nis suboptimal for the guest, and no well-behaved guest will request TLB\nflushes for non-canonical addresses.(CVE-2025-38351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks\n\nAfter retrieving WMI data blocks in sysfs callbacks, check for the\nvalidity of them before dereferencing their content.(CVE-2025-38412)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: do not bypass hid_hw_raw_request\n\nhid_hw_raw_request() is actually useful to ensure the provided buffer\nand length are valid. Directly calling in the low level transport driver\nfunction bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)\n\nIn the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net-\u0026gt;xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net-\u0026gt;collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)\n\nIn the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: \u0026apos;dma\u0026apos; and \u0026apos;page_dma\u0026apos;. However, only \u0026apos;page_dma\u0026apos; was actually initialized and used to program the Rx descriptor. But \u0026apos;dma\u0026apos; was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized \u0026apos;dma\u0026apos; was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)\n\nIn the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 \u0026amp; 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Prevent VMA split of buffer mappings\n\nThe perf mmap code is careful about mmap()\u0026apos;ing the user page with the\nringbuffer and additionally the auxiliary buffer, when the event supports\nit. Once the first mapping is established, subsequent mapping have to use\nthe same offset and the same size in both cases. The reference counting for\nthe ringbuffer and the auxiliary buffer depends on this being correct.\n\nThough perf does not prevent that a related mapping is split via mmap(2),\nmunmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,\nwhich take reference counts, but then the subsequent perf_mmap_close()\ncalls are not longer fulfilling the offset and size checks. This leads to\nreference count leaks.\n\nAs perf already has the requirement for subsequent mappings to match the\ninitial mapping, the obvious consequence is that VMA splits, caused by\nresizing of a mapping or partial unmapping, have to be prevented.\n\nImplement the vm_operations_struct::may_split() callback and return\nunconditionally -EINVAL.\n\nThat ensures that the mapping offsets and sizes cannot be changed after the\nfact. Remapping to a different fixed address with the same size is still\npossible as it takes the references for the new mapping and drops those of\nthe old mapping.(CVE-2025-38563)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbenet: fix BUG when creating VFs\n\nbenet crashes as soon as SRIOV VFs are created:\n\n kernel BUG at mm/vmalloc.c:3457!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)\n [...]\n RIP: 0010:vunmap+0x5f/0x70\n [...]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __iommu_dma_free+0xe8/0x1c0\n be_cmd_set_mac_list+0x3fe/0x640 [be2net]\n be_cmd_set_mac+0xaf/0x110 [be2net]\n be_vf_eth_addr_config+0x19f/0x330 [be2net]\n be_vf_setup+0x4f7/0x990 [be2net]\n be_pci_sriov_configure+0x3a1/0x470 [be2net]\n sriov_numvfs_store+0x20b/0x380\n kernfs_fop_write_iter+0x354/0x530\n vfs_write+0x9b9/0xf60\n ksys_write+0xf3/0x1d0\n do_syscall_64+0x8c/0x3d0\n\nbe_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.\nFix it by freeing only after the lock has been released.(CVE-2025-38569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmci: Prevent the dispatching of uninitialized payloads\n\nThe reproducer executes the host\u0026apos;s unlocked_ioctl call in two different\ntasks. When init_context fails, the struct vmci_event_ctx is not fully\ninitialized when executing vmci_datagram_dispatch() to send events to all\nvm contexts. This affects the datagram taken from the datagram queue of\nits context by another task, because the datagram payload is not initialized\naccording to the size payload_size, which causes the kernel data to leak\nto the user space.\n\nBefore dispatching the datagram, and before setting the payload content,\nexplicitly set the payload content to 0 to avoid data leakage caused by\nincomplete payload initialization.(CVE-2025-38611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 (\u0026quot;pinmux: Use sequential access to access\ndesc-\u0026gt;pinmux data\u0026quot;) tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc-\u0026gt;mux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n cpu0 (process A) cpu1 (process B)\n\n pin_request() { pin_free() {\n\n mutex_lock()\n desc-\u0026gt;mux_usecount--; //becomes 0\n ..\n mutex_unlock()\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_usecount++; // becomes 1\n desc-\u0026gt;mux_owner = owner;\n mutex_unlock(desc-\u0026gt;mux)\n\n mutex_lock(desc-\u0026gt;mux)\n desc-\u0026gt;mux_owner = NULL;\n mutex_unlock(desc-\u0026gt;mux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.(CVE-2025-38632)\n\nIn the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro\u0026apos;s suggestion, it was fixed in the same manner.(CVE-2025-38653)\n\nIn the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)",
"id": "OESA-2025-2122",
"modified": "2026-08-06T11:09:12Z",
"published": "2025-09-05T11:09:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2122"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21723"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21955"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22056"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22063"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22064"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22089"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22106"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37885"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37912"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37959"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37961"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37989"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37990"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38003"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38019"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38042"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38044"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38066"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38097"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38129"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38166"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38177"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38351"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38412"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38494"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38500"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38540"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38563"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38569"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38632"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38653"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38671"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21678",
"CVE-2025-21723",
"CVE-2025-21864",
"CVE-2025-21955",
"CVE-2025-22007",
"CVE-2025-22021",
"CVE-2025-22056",
"CVE-2025-22057",
"CVE-2025-22063",
"CVE-2025-22064",
"CVE-2025-22086",
"CVE-2025-22089",
"CVE-2025-22106",
"CVE-2025-37749",
"CVE-2025-37752",
"CVE-2025-37772",
"CVE-2025-37789",
"CVE-2025-37794",
"CVE-2025-37829",
"CVE-2025-37834",
"CVE-2025-37859",
"CVE-2025-37875",
"CVE-2025-37879",
"CVE-2025-37885",
"CVE-2025-37909",
"CVE-2025-37911",
"CVE-2025-37912",
"CVE-2025-37932",
"CVE-2025-37945",
"CVE-2025-37959",
"CVE-2025-37960",
"CVE-2025-37961",
"CVE-2025-37989",
"CVE-2025-37990",
"CVE-2025-38003",
"CVE-2025-38004",
"CVE-2025-38010",
"CVE-2025-38019",
"CVE-2025-38020",
"CVE-2025-38022",
"CVE-2025-38024",
"CVE-2025-38039",
"CVE-2025-38042",
"CVE-2025-38044",
"CVE-2025-38057",
"CVE-2025-38066",
"CVE-2025-38085",
"CVE-2025-38087",
"CVE-2025-38097",
"CVE-2025-38129",
"CVE-2025-38154",
"CVE-2025-38165",
"CVE-2025-38166",
"CVE-2025-38177",
"CVE-2025-38201",
"CVE-2025-38351",
"CVE-2025-38412",
"CVE-2025-38494",
"CVE-2025-38500",
"CVE-2025-38533",
"CVE-2025-38540",
"CVE-2025-38563",
"CVE-2025-38569",
"CVE-2025-38611",
"CVE-2025-38632",
"CVE-2025-38653",
"CVE-2025-38671"
]
}
oesa-2026-1341
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource(). And it s required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)
In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below: (Thread 1) | (Thread 2) | _set_timer()rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...We hold pmlmepriv->lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv->lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obtainthe needed lock. What`s more, we change spin_lock_bh() inrtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,spin_lock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)
In the Linux kernel, the following vulnerability has been resolved:
drm/scheduler: fix fence ref counting
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.(CVE-2022-49829)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix random warning message when driver load
Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] slaballoc.part.108+0x4d4/0x748 [ 4.191419] slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0
pool_alloc_page(struct dma_pool pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... }
kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning.
GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely.(CVE-2022-50151)
In the Linux kernel, the following vulnerability has been resolved:
of: check previous kernel's ima-kexec-buffer against memory bounds
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below:
$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
<snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---
Fix this issue by checking returned PFN range of previous kernel's ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.(CVE-2022-50159)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Use different devices for resource allocation and DT lookup
Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/(CVE-2022-50616)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: do not run mt76u_status_worker if the device is not running
Fix the following NULL pointer dereference avoiding to run mt76u_status_worker thread if the device is not running yet.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: mt76 mt76u_tx_status_data RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: mt76x02_send_tx_status+0x1d2/0xeb0 mt76x02_tx_status_data+0x8e/0xd0 mt76u_tx_status_data+0xe1/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480 ret_from_fork+0x1f/0x30 Modules linked in: --[ end trace 8df5d20fc5040f65 ]-- RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554
Moreover move stat_work schedule out of the for loop.(CVE-2022-50735)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: allow exp not to be removed in nf_ct_find_expectation
Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches.
This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.(CVE-2023-52927)
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 1373 Comm: modprobe Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:dmi_sysfs_entry_release ... Call Trace: <TASK> kobject_put dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs dmi_decode_table (drivers/firmware/dmi_scan.c:133) dmi_walk (drivers/firmware/dmi_scan.c:1115) dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs do_one_initcall (init/main.c:1296) ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x4000000 from 0xffffffff81000000 ---[ end Kernel panic - not syncing: Fatal exception ]---
It is because previous patch added kobject_put() to release the memory which will call dmi_sysfs_entry_release() and list_del().
However, list_add_tail(entry->list) is called after the error block, so the list_head is uninitialized and cannot be deleted.
Move error handling to after list_add_tail to fix this.(CVE-2023-53250)
In the Linux kernel, the following vulnerability has been resolved:
cacheinfo: Fix shared_cpu_map to handle shared caches at different levels
The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs.
CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3
This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013
When edev->components is zero, accessing edev->component[0] members is wrong.(CVE-2023-53521)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix resource leak in device_add()
When calling kobject_add() failed in device_add(), it will call cleanup_glue_dir() to free resource. But in kobject_add(), dev->kobj.parent has been set to NULL. This will cause resource leak.
The process is as follows: device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put()
The preceding problem may cause insmod mac80211_hwsim.ko to failed. sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim' Call Trace: <TASK> dump_stack_lvl+0x8e/0xd1 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x224/0x280 kobject_add_internal+0x2aa/0x880 kobject_add+0x135/0x1a0 get_device_parent+0x3d7/0x590 device_add+0x2aa/0x1cb0 device_create_groups_vargs+0x1eb/0x260 device_create+0xdc/0x110 mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim] init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim] do_one_initcall+0x10f/0x630 do_init_module+0x19f/0x5e0 load_module+0x64b7/0x6eb0 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to register things with the same name in the same directory.(CVE-2023-53594)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9317/1: kexec: Make smp stop calls asynchronous
If a panic is triggered by a hrtimer interrupt all online cpus will be notified and set offline. But as highlighted by commit 19dbdcb8039c ("smp: Warn on function calls from softirq context") this call should not be made synchronous with disabled interrupts:
softdog: Initiating panic Kernel panic - not syncing: Software Watchdog Timer expired WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond unwind_backtrace: show_stack dump_stack_lvl __warn warn_slowpath_fmt smp_call_function_many_cond smp_call_function crash_smp_send_stop.part.0 machine_crash_shutdown __crash_kexec panic softdog_fire __hrtimer_run_queues hrtimer_interrupt
Make the smp call for machine_crash_nonpanic_core() asynchronous.(CVE-2023-53712)
In the Linux kernel, the following vulnerability has been resolved:
usb: early: xhci-dbc: Fix a potential out-of-bound memory access
If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the string is not guaranteed to be NULL terminated when xdbc_trace() is called.
Reserve an extra byte, which will be zeroed automatically because 'buf' is a static variable, in order to avoid troubles, should it happen.(CVE-2023-53840)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Prevent handling any completions after qp destroy
HW may generate completions that indicates QP is destroyed. Driver should not be scheduling any more completion handlers for this QP, after the QP is destroyed. Since CQs are active during the QP destroy, driver may still schedule completion handlers. This can cause a race where the destroy_cq and poll_cq running simultaneously.
Snippet of kernel panic while doing bnxt_re driver load unload in loop. This indicates a poll after the CQ is freed.
[77786.481636] Call Trace: [77786.481640] <TASK> [77786.481644] bnxt_re_poll_cq+0x14a/0x620 [bnxt_re] [77786.481658] ? kvm_clock_read+0x14/0x30 [77786.481693] __ib_process_cq+0x57/0x190 [ib_core] [77786.481728] ib_cq_poll_work+0x26/0x80 [ib_core] [77786.481761] process_one_work+0x1e5/0x3f0 [77786.481768] worker_thread+0x50/0x3a0 [77786.481785] ? __pfx_worker_thread+0x10/0x10 [77786.481790] kthread+0xe2/0x110 [77786.481794] ? __pfx_kthread+0x10/0x10 [77786.481797] ret_from_fork+0x2c/0x50
To avoid this, complete all completion handlers before returning the destroy QP. If free_cq is called soon after destroy_qp, IB stack will cancel the CQ work before invoking the destroy_cq verb and this will prevent any race mentioned.(CVE-2023-54048)
In the Linux kernel, the following vulnerability has been resolved:
bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log
It's trivial for user to trigger "verifier log line truncated" warning, as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at least two pieces of user-provided information that can be output through this buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.
Verifier log buffer should be properly sized for typical verifier state output. But it's sort-of expected that this buffer won't be long enough in some circumstances. So let's drop the check. In any case code will work correctly, at worst truncating a part of a single line output.(CVE-2023-54145)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential null-ptr-deref in device_add()
I got the following null-ptr-deref report while doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482]
This is how it happened:
w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device.
// error path
bus_remove_device()
// The dev->driver is not null, but driver is not bound.
__device_release_driver()
klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.
// normal path
bus_probe_device() // It's not called yet.
device_bind_driver()
If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device().(CVE-2023-54321)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free of signing key
Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race:
task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() UAF
Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING.(CVE-2024-53179)
In the Linux kernel, the following vulnerability has been resolved:
ice: fix memory leak in aRFS after reset
Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling
However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature:
[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ...(CVE-2025-21981)
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: fix pipe accounting mismatch
Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.
To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers()
(It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?)(CVE-2025-23138)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: prevent out-of-bounds stream writes by validating *pos
ksmbd_vfs_stream_write() did not validate whether the write offset (pos) was within the bounds of the existing stream data length (v_len). If pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write.
This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)
In the Linux kernel, the following vulnerability has been resolved:
crypto: lzo - Fix compression buffer overrun
Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller.
Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.
Race conditions: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''
The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''
Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread and close() thread.
The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix use-after-free in vhci_flush()
syzbot reported use-after-free in vhci_flush() without repro. [0]
From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread.
Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data.
The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation.
We can use SRCU for such synchronisation.
Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev().
Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 ("Bluetooth: Remove unused hci-destruct cb"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat.
Note that other drivers seem to have the same problem, for exmaple, virtbt_remove().
[0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718
CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 </TASK>
Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---(CVE-2025-38250)
In the Linux kernel, the following vulnerability has been resolved:
comedi: Fix use of uninitialized data in insn_rw_emulate_bits()
For Comedi INSN_READ and INSN_WRITE instructions on "digital"
subdevices (subdevice types COMEDI_SUBD_DI, COMEDI_SUBD_DO, and
COMEDI_SUBD_DIO), it is common for the subdevice driver not to have
insn_read and insn_write handler functions, but to have an
insn_bits handler function for handling Comedi INSN_BITS
instructions. In that case, the subdevice's insn_read and/or
insn_write function handler pointers are set to point to the
insn_rw_emulate_bits() function by __comedi_device_postconfig().
For INSN_WRITE, insn_rw_emulate_bits() currently assumes that the
supplied data[0] value is a valid copy from user memory. It will at
least exist because do_insnlist_ioctl() and do_insn_ioctl() in
"comedi_fops.c" ensure at lease MIN_SAMPLES (16) elements are
allocated. However, if insn->n is 0 (which is allowable for
INSN_READ and INSN_WRITE instructions, then data[0] may contain
uninitialized data, and certainly contains invalid data, possibly from a
different instruction in the array of instructions handled by
do_insnlist_ioctl(). This will result in an incorrect value being
written to the digital output channel (or to the digital input/output
channel if configured as an output), and may be reflected in the
internal saved state of the channel.
Fix it by returning 0 early if insn->n is 0, before reaching the code
that accesses data[0]. Previously, the function always returned 1 on
success, but it is supposed to be the number of data samples actually
read or written up to insn->n, which is 0 in this case.(CVE-2025-38480)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that.
Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.(CVE-2025-38556)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: reject malicious packets in ipv6_gso_segment()
syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.
This 16bit field has a limited range.
Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment()
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptp_xmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge()
We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 _syssendmsg+0x893/0xd80 net/socket.c:2566 _sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Do not allow binding to VMADDR_PORT_ANY
It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).
Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY.(CVE-2025-38618)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Avoid stack buffer overflow from kernel cmdline
While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix for slab out of bounds on mount to ksmbd
With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below):
BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827
CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 cifs
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla4xxx: Prevent a potential error pointer dereference
The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error, but qla4xxx_ep_connect() returns error pointers. Propagating the error pointers will lead to an Oops in the caller, so change the error pointers to NULL.(CVE-2025-39676)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.(CVE-2025-39702)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.
irq_exit() __irq_exit_rcu() / in_hardirq() returns false after this / preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() / a bpf prog is hooked on this trace point / __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() / will send a IPI to itself / irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +
neeraj: Apply Frederic's suggested fix for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
rcu: Protect ->defer_qs_iw_pending from data race
On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.
In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.
The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:
BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special
read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0
The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.
This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Duplicate SPI Handling
The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.
This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.
According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.
Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.
Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI
Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.(CVE-2025-39797)
In the Linux kernel, the following vulnerability has been resolved:
atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().
syzbot reported the splat below. [0]
When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.
The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.
The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.
struct atmtcp_control { struct atmtcp_hdr hdr; / must be first / ... atm_kptr_t vcc; / both directions / ... } __ATM_API_ALIGN;
typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;
The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().
atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:
- .ndo_start_xmit() (vcc->send() == atm_send_aal0())
- vcc_sendmsg()
The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.
Let's add a new ->pre_send() hook to validate messages from sendmsg().
[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 _syssendmsg+0x505/0x830 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
syzbot reported the splat below without a repro.
In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that.
The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit.
bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release().
Two threads could see the same socket during the list iteration in bt_accept_dequeue():
CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF
Depending on the timing, the other thread could show up in the "Freed by task" part.
Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release().
[0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>
Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---(CVE-2025-39860)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
syzbot reported the splat below. [0]
The repro does the following:
- Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
- Attach the prog to a SOCKMAP
- Add a socket to the SOCKMAP
- Activate fault injection
- Send data less than cork_bytes
At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.
If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().
Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.
The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.
[0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)
In the Linux kernel, the following vulnerability has been resolved:
cnic: Fix use-after-free bugs in cnic_delete_task
The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task().
A typical race condition is illustrated below:
CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | / the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed.
This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: Defer ip_vs_ftp unregister during netns cleanup
On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.
Fix this by introducing a global exiting_module flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.(CVE-2025-40018)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't leak disconnected dentries on umount
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete x->tunnel as we delete x
The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.
We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.
Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.
A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.(CVE-2025-40215)
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_mon_reinit_self().
syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0]
The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL.
tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work().
Let's hold RTNL in tipc_net_finalize_work().
[0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989
CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 _syssendmsg+0x508/0x820 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/ ---truncated---(CVE-2025-40280)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: use lock accessing port_state and rport state
nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.(CVE-2025-40342)
In the Linux kernel, the following vulnerability has been resolved:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup
Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks.
Initialize the MAC header to prevent such crashes.
This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface.
Example trace:
Internal error: Oops: 000000009600004f [#1] SMP
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
Hardware name: LS1028A RDB Board (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xfrm_input+0xde8/0x1318
lr : xfrm_input+0x61c/0x1318
sp : ffff800080003b20
Call trace:
xfrm_input+0xde8/0x1318
xfrm6_rcv+0x38/0x44
xfrm6_esp_rcv+0x48/0xa8
ip6_protocol_deliver_rcu+0x94/0x4b0
ip6_input_finish+0x44/0x70
ip6_input+0x44/0xc0
ipv6_rcv+0x6c/0x114
__netif_receive_skb_one_core+0x5c/0x8c
__netif_receive_skb+0x18/0x60
process_backlog+0x78/0x17c
__napi_poll+0x38/0x180
net_rx_action+0x168/0x2f0(CVE-2025-68192)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix potential use-after-free in have_mon_and_osd_map()
The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one
kfree(monc->monmap);
monc->monmap = monmap;
ceph_osdmap_destroy(osdc->osdmap);
osdc->osdmap = newmap;
under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in
client->monc.monmap && client->monc.monmap->epoch &&
client->osdc.osdmap && client->osdc.osdmap->epoch;
condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:
BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
...
Call Trace:
<TASK>
have_mon_and_osd_map+0x56/0x70
ceph_open_session+0x182/0x290
ceph_get_tree+0x333/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Allocated by task 13305:
ceph_osdmap_alloc+0x16/0x130
ceph_osdc_init+0x27a/0x4c0
ceph_create_client+0x153/0x190
create_fs_client+0x50/0x2a0
ceph_get_tree+0xff/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 9475:
kfree+0x212/0x290
handle_one_map+0x23c/0x3b0
ceph_osdc_handle_map+0x3c9/0x590
mon_dispatch+0x655/0x6f0
ceph_con_process_message+0xc3/0xe0
ceph_con_v1_try_read+0x614/0x760
ceph_con_workfn+0x2de/0x650
process_one_work+0x486/0x7c0
process_scheduled_works+0x73/0x90
worker_thread+0x1c8/0x2a0
kthread+0x2ec/0x300
ret_from_fork+0x24/0x40
ret_from_fork_asm+0x1a/0x30
Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth().
monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.(CVE-2025-68285)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()
rlen value is a user-controlled value, but dtv5100_i2c_msg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.
Therefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cm: Fix leaking the multicast GID table reference
If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ah_attr after canceling the work, it is safe to call this twice.(CVE-2025-71084)
In the Linux kernel, the following vulnerability has been resolved:
team: fix check for port enabled in team_queue_override_port_prio_changed()
There has been a syzkaller bug reported recently with the following trace:
list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:59! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] _syssendmsg+0xa98/0xc70 net/socket.c:2630 _sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The problem is in this flow: 1) Port is enabled, queue_id != 0, in qom_list 2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list) 3) Port is disabled, queue_id != 0, not in any list 4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed already
To fix this, change the check in team_queue_override_port_prio_changed() so it returns early if port is not enabled.(CVE-2025-71091)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf
A zero length gss_token results in pages == 0 and in_token->pages[0] is NULL. The code unconditionally evaluates page_address(in_token->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.(CVE-2025-71120)
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs.
The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated(CVE-2026-22998)
In the Linux kernel, the following vulnerability has been resolved:
pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()
In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak.
Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"perf-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-301.0.0.204.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"perf-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-301.0.0.204.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-301.0.0.204.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:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource(). And it s required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)\n\nIn the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below: (Thread 1) | (Thread 2) | _set_timer()rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...We hold pmlmepriv-\u0026gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-\u0026gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obtainthe needed lock. What`s more, we change spin_lock_bh() inrtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,spin_lock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: fix fence ref counting\n\nWe leaked dependency fences when processes were beeing killed.\n\nAdditional to that grab a reference to the last scheduled fence.(CVE-2022-49829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix random warning message when driver load\n\nWarning log:\n[ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!\n[ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20\n[ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)\n[ 4.163155] Call trace:\n[ 4.165600] dump_backtrace+0x0/0x1b0\n[ 4.169286] show_stack+0x18/0x68\n[ 4.172611] dump_stack_lvl+0x68/0x84\n[ 4.176286] dump_stack+0x18/0x34\n[ 4.179613] kmalloc_fix_flags+0x60/0x88\n[ 4.183550] new_slab+0x334/0x370\n[ 4.186878] ___slab_alloc.part.108+0x4d4/0x748\n[ 4.191419] __slab_alloc.isra.109+0x30/0x78\n[ 4.195702] kmem_cache_alloc+0x40c/0x420\n[ 4.199725] dma_pool_alloc+0xac/0x1f8\n[ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0\n\npool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)\n{\n\t...\n\tpage = kmalloc(sizeof(*page), mem_flags);\n\tpage-\u0026gt;vaddr = dma_alloc_coherent(pool-\u0026gt;dev, pool-\u0026gt;allocation,\n\t\t\t\t\t \u0026amp;page-\u0026gt;dma, mem_flags);\n\t...\n}\n\nkmalloc was called with mem_flags, which is passed down in\ncdns3_allocate_trb_pool() and have GFP_DMA32 flags.\nkmall_fix_flags() report warning.\n\nGFP_DMA32 is not useful at all. dma_alloc_coherent() will handle\nDMA memory region correctly by pool-\u0026gt;dev. GFP_DMA32 can be removed\nsafely.(CVE-2022-50151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nof: check previous kernel\u0026apos;s ima-kexec-buffer against memory bounds\n\nPresently ima_get_kexec_buffer() doesn\u0026apos;t check if the previous kernel\u0026apos;s\nima-kexec-buffer lies outside the addressable memory range. This can result\nin a kernel panic if the new kernel is booted with \u0026apos;mem=X\u0026apos; arg and the\nima-kexec-buffer was allocated beyond that range by the previous kernel.\nThe panic is usually of the form below:\n\n$ sudo kexec --initrd initrd vmlinux --append=\u0026apos;mem=16G\u0026apos;\n\n\u0026lt;snip\u0026gt;\n BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000\n Faulting instruction address: 0xc000000000837974\n Oops: Kernel access of bad area, sig: 11 [#1]\n\u0026lt;snip\u0026gt;\n NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0\n LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160\n Call Trace:\n [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160\n [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108\n [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120\n [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0\n [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec\n [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0\n [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64\n Instruction dump:\n f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330\n 7c0802a6 fb610198 7c9b2378 f80101d0 \u0026lt;a1240000\u0026gt; 2c090001 40820614 e9240010\n ---[ end trace 0000000000000000 ]---\n\nFix this issue by checking returned PFN range of previous kernel\u0026apos;s\nima-kexec-buffer with page_is_ram() to ensure correct memory bounds.(CVE-2022-50159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Use different devices for resource allocation and DT lookup\n\nFollowing by the below discussion, there\u0026apos;s the potential UAF issue\nbetween regulator and mfd.\nhttps://lore.kernel.org/all/(CVE-2022-50616)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: do not run mt76u_status_worker if the device is not running\n\nFix the following NULL pointer dereference avoiding to run\nmt76u_status_worker thread if the device is not running yet.\n\nKASAN: null-ptr-deref in range\n[0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware\nname: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: mt76 mt76u_tx_status_data\nRIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0\nCode: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00\n48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 \u0026lt;0f\u0026gt;\nb6\n04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7\nRSP: 0018:ffffc900005af988 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a\nRBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c\nR10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8\nR13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28\nFS: 0000000000000000(0000) GS:ffff88811aa00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n mt76x02_send_tx_status+0x1d2/0xeb0\n mt76x02_tx_status_data+0x8e/0xd0\n mt76u_tx_status_data+0xe1/0x240\n process_one_work+0x92b/0x1460\n worker_thread+0x95/0xe00\n kthread+0x3a1/0x480\n ret_from_fork+0x1f/0x30\nModules linked in:\n--[ end trace 8df5d20fc5040f65 ]--\nRIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0\nCode: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00\n48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 \u0026lt;0f\u0026gt;\nb6\n04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7\nRSP: 0018:ffffc900005af988 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a\nRBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c\nR10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8\nR13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28\nFS: 0000000000000000(0000) GS:ffff88811aa00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0\nPKRU: 55555554\n\nMoreover move stat_work schedule out of the for loop.(CVE-2022-50735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: allow exp not to be removed in nf_ct_find_expectation\n\nCurrently nf_conntrack_in() calling nf_ct_find_expectation() will\nremove the exp from the hash table. However, in some scenario, we\nexpect the exp not to be removed when the created ct will not be\nconfirmed, like in OVS and TC conntrack in the following patches.\n\nThis patch allows exp not to be removed by setting IPS_CONFIRMED\nin the status of the tmpl.(CVE-2023-52927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle\n\nKASAN reported a null-ptr-deref error:\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 1373 Comm: modprobe\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:dmi_sysfs_entry_release\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kobject_put\n dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs\n dmi_decode_table (drivers/firmware/dmi_scan.c:133)\n dmi_walk (drivers/firmware/dmi_scan.c:1115)\n dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs\n do_one_initcall (init/main.c:1296)\n ...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x4000000 from 0xffffffff81000000\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nIt is because previous patch added kobject_put() to release the memory\nwhich will call dmi_sysfs_entry_release() and list_del().\n\nHowever, list_add_tail(entry-\u0026gt;list) is called after the error block,\nso the list_head is uninitialized and cannot be deleted.\n\nMove error handling to after list_add_tail to fix this.(CVE-2023-53250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Fix shared_cpu_map to handle shared caches at different levels\n\nThe cacheinfo sets up the shared_cpu_map by checking whether the caches\nwith the same index are shared between CPUs. However, this will trigger\nslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.\nAnother problem is the mismatched shared_cpu_map when the shared cache does\nnot have the same index between CPUs.\n\nCPU0\tI\tD\tL3\nindex\t0\t1\t2\tx\n\t^\t^\t^\t^\nindex\t0\t1\t2\t3\nCPU1\tI\tD\tL2\tL3\n\nThis patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix slab-out-of-bounds in ses_intf_remove()\n\nA fix for:\n\nBUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]\nRead of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013\n\nWhen edev-\u0026gt;components is zero, accessing edev-\u0026gt;component[0] members is\nwrong.(CVE-2023-53521)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix resource leak in device_add()\n\nWhen calling kobject_add() failed in device_add(), it will call\ncleanup_glue_dir() to free resource. But in kobject_add(),\ndev-\u0026gt;kobj.parent has been set to NULL. This will cause resource leak.\n\nThe process is as follows:\ndevice_add()\n\tget_device_parent()\n\t\tclass_dir_create_and_add()\n\t\t\tkobject_add()\t\t//kobject_get()\n\t...\n\tdev-\u0026gt;kobj.parent = kobj;\n\t...\n\tkobject_add()\t\t//failed, but set dev-\u0026gt;kobj.parent = NULL\n\t...\n\tglue_dir = get_glue_dir(dev)\t//glue_dir = NULL, and goto\n\t\t\t\t\t//\u0026quot;Error\u0026quot; label\n\t...\n\tcleanup_glue_dir()\t//becaues glue_dir is NULL, not call\n\t\t\t\t//kobject_put()\n\nThe preceding problem may cause insmod mac80211_hwsim.ko to failed.\nsysfs: cannot create duplicate filename \u0026apos;/devices/virtual/mac80211_hwsim\u0026apos;\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x8e/0xd1\nsysfs_warn_dup.cold+0x1c/0x29\nsysfs_create_dir_ns+0x224/0x280\nkobject_add_internal+0x2aa/0x880\nkobject_add+0x135/0x1a0\nget_device_parent+0x3d7/0x590\ndevice_add+0x2aa/0x1cb0\ndevice_create_groups_vargs+0x1eb/0x260\ndevice_create+0xdc/0x110\nmac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]\ninit_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]\ndo_one_initcall+0x10f/0x630\ndo_init_module+0x19f/0x5e0\nload_module+0x64b7/0x6eb0\n__do_sys_finit_module+0x140/0x200\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\n\u0026lt;/TASK\u0026gt;\nkobject_add_internal failed for mac80211_hwsim with -EEXIST, don\u0026apos;t try to\nregister things with the same name in the same directory.(CVE-2023-53594)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9317/1: kexec: Make smp stop calls asynchronous\n\nIf a panic is triggered by a hrtimer interrupt all online cpus will be\nnotified and set offline. But as highlighted by commit 19dbdcb8039c\n(\u0026quot;smp: Warn on function calls from softirq context\u0026quot;) this call should\nnot be made synchronous with disabled interrupts:\n\n softdog: Initiating panic\n Kernel panic - not syncing: Software Watchdog Timer expired\n WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond\n unwind_backtrace:\n show_stack\n dump_stack_lvl\n __warn\n warn_slowpath_fmt\n smp_call_function_many_cond\n smp_call_function\n crash_smp_send_stop.part.0\n machine_crash_shutdown\n __crash_kexec\n panic\n softdog_fire\n __hrtimer_run_queues\n hrtimer_interrupt\n\nMake the smp call for machine_crash_nonpanic_core() asynchronous.(CVE-2023-53712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: early: xhci-dbc: Fix a potential out-of-bound memory access\n\nIf xdbc_bulk_write() fails, the values in \u0026apos;buf\u0026apos; can be anything. So the\nstring is not guaranteed to be NULL terminated when xdbc_trace() is called.\n\nReserve an extra byte, which will be zeroed automatically because \u0026apos;buf\u0026apos; is\na static variable, in order to avoid troubles, should it happen.(CVE-2023-53840)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Prevent handling any completions after qp destroy\n\nHW may generate completions that indicates QP is destroyed.\nDriver should not be scheduling any more completion handlers\nfor this QP, after the QP is destroyed. Since CQs are active\nduring the QP destroy, driver may still schedule completion\nhandlers. This can cause a race where the destroy_cq and poll_cq\nrunning simultaneously.\n\nSnippet of kernel panic while doing bnxt_re driver load unload in loop.\nThis indicates a poll after the CQ is freed.\u00a0\n\n[77786.481636] Call Trace:\n[77786.481640] \u00a0\u0026lt;TASK\u0026gt;\n[77786.481644] \u00a0bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]\n[77786.481658] \u00a0? kvm_clock_read+0x14/0x30\n[77786.481693] \u00a0__ib_process_cq+0x57/0x190 [ib_core]\n[77786.481728] \u00a0ib_cq_poll_work+0x26/0x80 [ib_core]\n[77786.481761] \u00a0process_one_work+0x1e5/0x3f0\n[77786.481768] \u00a0worker_thread+0x50/0x3a0\n[77786.481785] \u00a0? __pfx_worker_thread+0x10/0x10\n[77786.481790] \u00a0kthread+0xe2/0x110\n[77786.481794] \u00a0? __pfx_kthread+0x10/0x10\n[77786.481797] \u00a0ret_from_fork+0x2c/0x50\n\nTo avoid this, complete all completion handlers before returning the\ndestroy QP. If free_cq is called soon after destroy_qp, IB stack\nwill cancel the CQ work before invoking the destroy_cq verb and\nthis will prevent any race mentioned.(CVE-2023-54048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log\n\nIt\u0026apos;s trivial for user to trigger \u0026quot;verifier log line truncated\u0026quot; warning,\nas verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at\nleast two pieces of user-provided information that can be output through\nthis buffer, and both can be arbitrarily sized by user:\n - BTF names;\n - BTF.ext source code lines strings.\n\nVerifier log buffer should be properly sized for typical verifier state\noutput. But it\u0026apos;s sort-of expected that this buffer won\u0026apos;t be long enough\nin some circumstances. So let\u0026apos;s drop the check. In any case code will\nwork correctly, at worst truncating a part of a single line output.(CVE-2023-54145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential null-ptr-deref in device_add()\n\nI got the following null-ptr-deref report while doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nCPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x196/0x210\n bus_remove_device+0x1bd/0x240\n device_add+0xd3d/0x1100\n w1_add_master_device+0x476/0x490 [wire]\n ds2482_probe+0x303/0x3e0 [ds2482]\n\nThis is how it happened:\n\nw1_alloc_dev()\n // The dev-\u0026gt;driver is set to w1_master_driver.\n memcpy(\u0026amp;dev-\u0026gt;dev, device, sizeof(struct device));\n device_add()\n bus_add_device()\n dpm_sysfs_add() // It fails, calls bus_remove_device.\n\n // error path\n bus_remove_device()\n // The dev-\u0026gt;driver is not null, but driver is not bound.\n __device_release_driver()\n klist_remove(\u0026amp;dev-\u0026gt;p-\u0026gt;knode_driver) \u0026lt;-- It causes null-ptr-deref.\n\n // normal path\n bus_probe_device() // It\u0026apos;s not called yet.\n device_bind_driver()\n\nIf dev-\u0026gt;driver is set, in the error path after calling bus_add_device()\nin device_add(), bus_remove_device() is called, then the device will be\ndetached from driver. But device_bind_driver() is not called yet, so it\ncauses null-ptr-deref while access the \u0026apos;knode_driver\u0026apos;. To fix this, set\ndev-\u0026gt;driver to null in the error path before calling bus_remove_device().(CVE-2023-54321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free of signing key\n\nCustomers have reported use-after-free in @ses-\u0026gt;auth_key.response with\nSMB2.1 + sign mounts which occurs due to following race:\n\ntask A task B\ncifs_mount()\n dfs_mount_share()\n get_session()\n cifs_mount_get_session() cifs_send_recv()\n cifs_get_smb_ses() compound_send_recv()\n cifs_setup_session() smb2_setup_request()\n kfree_sensitive() smb2_calc_signature()\n crypto_shash_setkey() *UAF*\n\nFix this by ensuring that we have a valid @ses-\u0026gt;auth_key.response by\nchecking whether @ses-\u0026gt;ses_status is SES_GOOD or SES_EXITING with\n@ses-\u0026gt;ses_lock held. After commit 24a9799aa8ef (\u0026quot;smb: client: fix UAF\nin smb2_reconnect_server()\u0026quot;), we made sure to call -\u0026gt;logoff() only\nwhen @ses was known to be good (e.g. valid -\u0026gt;auth_key.response), so\nit\u0026apos;s safe to access signing key when @ses-\u0026gt;ses_status == SES_EXITING.(CVE-2024-53179)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix memory leak in aRFS after reset\n\nFix aRFS (accelerated Receive Flow Steering) structures memory leak by\nadding a checker to verify if aRFS memory is already allocated while\nconfiguring VSI. aRFS objects are allocated in two cases:\n- as part of VSI initialization (at probe), and\n- as part of reset handling\n\nHowever, VSI reconfiguration executed during reset involves memory\nallocation one more time, without prior releasing already allocated\nresources. This led to the memory leak with the following signature:\n\n[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak\nunreferenced object 0xff3c1ca7252e6000 (size 8192):\n comm \u0026quot;kworker/0:0\u0026quot;, pid 8, jiffies 4296833052\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 0):\n [\u0026lt;ffffffff991ec485\u0026gt;] __kmalloc_cache_noprof+0x275/0x340\n [\u0026lt;ffffffffc0a6e06a\u0026gt;] ice_init_arfs+0x3a/0xe0 [ice]\n [\u0026lt;ffffffffc09f1027\u0026gt;] ice_vsi_cfg_def+0x607/0x850 [ice]\n [\u0026lt;ffffffffc09f244b\u0026gt;] ice_vsi_setup+0x5b/0x130 [ice]\n [\u0026lt;ffffffffc09c2131\u0026gt;] ice_init+0x1c1/0x460 [ice]\n [\u0026lt;ffffffffc09c64af\u0026gt;] ice_probe+0x2af/0x520 [ice]\n [\u0026lt;ffffffff994fbcd3\u0026gt;] local_pci_probe+0x43/0xa0\n [\u0026lt;ffffffff98f07103\u0026gt;] work_for_cpu_fn+0x13/0x20\n [\u0026lt;ffffffff98f0b6d9\u0026gt;] process_one_work+0x179/0x390\n [\u0026lt;ffffffff98f0c1e9\u0026gt;] worker_thread+0x239/0x340\n [\u0026lt;ffffffff98f14abc\u0026gt;] kthread+0xcc/0x100\n [\u0026lt;ffffffff98e45a6d\u0026gt;] ret_from_fork+0x2d/0x50\n [\u0026lt;ffffffff98e083ba\u0026gt;] ret_from_fork_asm+0x1a/0x30\n ...(CVE-2025-21981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: fix pipe accounting mismatch\n\nCurrently, watch_queue_set_size() modifies the pipe buffers charged to\nuser-\u0026gt;pipe_bufs without updating the pipe-\u0026gt;nr_accounted on the pipe\nitself, due to the if (!pipe_has_watch_queue()) test in\npipe_resize_ring(). This means that when the pipe is ultimately freed,\nwe decrement user-\u0026gt;pipe_bufs by something other than what than we had\ncharged to it, potentially leading to an underflow. This in turn can\ncause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.\n\nTo remedy this, explicitly account for the pipe usage in\nwatch_queue_set_size() to match the number set via account_pipe_buffers()\n\n(It\u0026apos;s unclear why watch_queue_set_size() does not update nr_accounted;\nit may be due to intentional overprovisioning in watch_queue_set_size()?)(CVE-2025-23138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent out-of-bounds stream writes by validating *pos\n\nksmbd_vfs_stream_write() did not validate whether the write offset\n(*pos) was within the bounds of the existing stream data length (v_len).\nIf *pos was greater than or equal to v_len, this could lead to an\nout-of-bounds memory write.\n\nThis patch adds a check to ensure *pos is less than v_len before\nproceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: lzo - Fix compression buffer overrun\n\nUnlike the decompression code, the compression code in LZO never\nchecked for output overruns. It instead assumes that the caller\nalways provides enough buffer space, disregarding the buffer length\nprovided by the caller.\n\nAdd a safe compression interface that checks for the end of buffer\nbefore each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u0026gt;sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0026apos;\u0026apos;\u0026apos;\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u0026gt;release() -\u0026gt; sock_map_close()\n sk_socket-\u0026gt;ops = NULL\n free(socket)\n sock-\u0026gt;ops-\u0026gt;sendmsg\n ^\n panic here\n\u0026apos;\u0026apos;\u0026apos;\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0026apos;\u0026apos;\u0026apos;\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u0026lt;=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0026apos;\u0026apos;\u0026apos;\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0026apos;t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0026apos;\u0026apos;\u0026apos;\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0026apos;\u0026apos;\u0026apos;(CVE-2025-38154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix use-after-free in vhci_flush()\n\nsyzbot reported use-after-free in vhci_flush() without repro. [0]\n\nFrom the splat, a thread close()d a vhci file descriptor while\nits device was being used by iotcl() on another thread.\n\nOnce the last fd refcnt is released, vhci_release() calls\nhci_unregister_dev(), hci_free_dev(), and kfree() for struct\nvhci_data, which is set to hci_dev-\u0026gt;dev-\u0026gt;driver_data.\n\nThe problem is that there is no synchronisation after unlinking\nhdev from hci_dev_list in hci_unregister_dev(). There might be\nanother thread still accessing the hdev which was fetched before\nthe unlink operation.\n\nWe can use SRCU for such synchronisation.\n\nLet\u0026apos;s run hci_dev_reset() under SRCU and wait for its completion\nin hci_unregister_dev().\n\nAnother option would be to restore hci_dev-\u0026gt;destruct(), which was\nremoved in commit 587ae086f6e4 (\u0026quot;Bluetooth: Remove unused\nhci-destruct cb\u0026quot;). However, this would not be a good solution, as\nwe should not run hci_unregister_dev() while there are in-flight\nioctl() requests, which could lead to another data-race KCSAN splat.\n\nNote that other drivers seem to have the same problem, for exmaple,\nvirtbt_remove().\n\n[0]:\nBUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]\nBUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937\nRead of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718\n\nCPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]\n skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937\n skb_queue_purge include/linux/skbuff.h:3368 [inline]\n vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69\n hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]\n hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592\n sock_do_ioctl+0xd9/0x300 net/socket.c:1190\n sock_ioctl+0x576/0x790 net/socket.c:1311\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fcf5b98e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929\nRDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009\nRBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 6535:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635\n misc_open+0x2bc/0x330 drivers/char/misc.c:161\n chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414\n do_dentry_open+0xdf0/0x1970 fs/open.c:964\n vfs_open+0x3b/0x340 fs/open.c:1094\n do_open fs/namei.c:3887 [inline]\n path_openat+0x2ee5/0x3830 fs/name\n---truncated---(CVE-2025-38250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Fix use of uninitialized data in insn_rw_emulate_bits()\n\nFor Comedi `INSN_READ` and `INSN_WRITE` instructions on \u0026quot;digital\u0026quot;\nsubdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and\n`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have\n`insn_read` and `insn_write` handler functions, but to have an\n`insn_bits` handler function for handling Comedi `INSN_BITS`\ninstructions. In that case, the subdevice\u0026apos;s `insn_read` and/or\n`insn_write` function handler pointers are set to point to the\n`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.\n\nFor `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the\nsupplied `data[0]` value is a valid copy from user memory. It will at\nleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in\n\u0026quot;comedi_fops.c\u0026quot; ensure at lease `MIN_SAMPLES` (16) elements are\nallocated. However, if `insn-\u0026gt;n` is 0 (which is allowable for\n`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain\nuninitialized data, and certainly contains invalid data, possibly from a\ndifferent instruction in the array of instructions handled by\n`do_insnlist_ioctl()`. This will result in an incorrect value being\nwritten to the digital output channel (or to the digital input/output\nchannel if configured as an output), and may be reflected in the\ninternal saved state of the channel.\n\nFix it by returning 0 early if `insn-\u0026gt;n` is 0, before reaching the code\nthat accesses `data[0]`. Previously, the function always returned 1 on\nsuccess, but it is supposed to be the number of data samples actually\nread or written up to `insn-\u0026gt;n`, which is 0 in this case.(CVE-2025-38480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity. Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn\u0026apos;t reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.(CVE-2025-38556)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: reject malicious packets in ipv6_gso_segment()\n\nsyzbot was able to craft a packet with very long IPv6 extension headers\nleading to an overflow of skb-\u0026gt;transport_header.\n\nThis 16bit field has a limited range.\n\nAdd skb_reset_transport_header_careful() helper and use it\nfrom ipv6_gso_segment()\n\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nModules linked in:\nCPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\n RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\n RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n __skb_gso_segment+0x342/0x510 net/core/gso.c:124\n skb_gso_segment include/net/gso.h:83 [inline]\n validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950\n validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000\n sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329\n __dev_xmit_skb net/core/dev.c:4102 [inline]\n __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npptp: ensure minimal skb length in pptp_xmit()\n\nCommit aabc6596ffb3 (\u0026quot;net: ppp: Add bound checking for skb data\non ppp_sync_txmung\u0026quot;) fixed ppp_sync_txmunge()\n\nWe need a similar fix in pptp_xmit(), otherwise we might\nread uninit data as reported by syzbot.\n\nBUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]\n ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314\n pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:727\n ____sys_sendmsg+0x893/0xd80 net/socket.c:2566\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620\n __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Do not allow binding to VMADDR_PORT_ANY\n\nIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This can\ncause a use-after-free when a connection is made to the bound socket.\nThe socket returned by accept() also has port VMADDR_PORT_ANY but is not\non the list of unbound sockets. Binding it will result in an extra\nrefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep\nthe binding until socket destruction).\n\nModify the check in __vsock_bind_connectible() to also prevent binding\nto VMADDR_PORT_ANY.(CVE-2025-38618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix for slab out of bounds on mount to ksmbd\n\nWith KASAN enabled, it is possible to get a slab out of bounds\nduring mount to ksmbd due to missing check in parse_server_interfaces()\n(see below):\n\n BUG: KASAN: slab-out-of-bounds in\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n Read of size 4 at addr ffff8881433dba98 by task mount/9827\n\n CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G\n OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary)\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,\n BIOS 2.13.1 06/14/2019\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x9f/0xf0\n print_report+0xd1/0x670\n __virt_addr_valid+0x22c/0x430\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? kasan_complete_mode_report_info+0x2a/0x1f0\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n kasan_report+0xd6/0x110\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n __asan_report_load_n_noabort+0x13/0x20\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]\n ? trace_hardirqs_on+0x51/0x60\n SMB3_request_interfaces+0x1ad/0x3f0 [cifs]\n ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]\n ? SMB2_tcon+0x23c/0x15d0 [cifs]\n smb3_qfs_tcon+0x173/0x2b0 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n cifs_mount_get_tcon+0x369/0xb90 [cifs]\n ? dfs_cache_find+0xe7/0x150 [cifs]\n dfs_mount_share+0x985/0x2970 [cifs]\n ? check_path.constprop.0+0x28/0x50\n ? save_trace+0x54/0x370\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? __lock_acquire+0xb82/0x2ba0\n ? __kasan_check_write+0x18/0x20\n cifs_mount+0xbc/0x9e0 [cifs]\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]\n cifs_smb3_do_mount+0x263/0x1990 [cifs](CVE-2025-38728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Prevent a potential error pointer dereference\n\nThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,\nbut qla4xxx_ep_connect() returns error pointers. Propagating the error\npointers will lead to an Oops in the caller, so change the error pointers\nto NULL.(CVE-2025-39676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: Fix MAC comparison to be constant-time\n\nTo prevent timing attacks, MACs need to be compared in constant time.\nUse the appropriate helper function for this.(CVE-2025-39702)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix rcu_read_unlock() deadloop due to IRQ work\n\nDuring rcu_read_unlock_special(), if this happens during irq_exit(), we\ncan lockup if an IPI is issued. This is because the IPI itself triggers\nthe irq_exit() path causing a recursive lock up.\n\nThis is precisely what Xiongfeng found when invoking a BPF program on\nthe trace_tick_stop() tracepoint As shown in the trace below. Fix by\nmanaging the irq_work state correctly.\n\nirq_exit()\n __irq_exit_rcu()\n /* in_hardirq() returns false after this */\n preempt_count_sub(HARDIRQ_OFFSET)\n tick_irq_exit()\n tick_nohz_irq_exit()\n\t tick_nohz_stop_sched_tick()\n\t trace_tick_stop() /* a bpf prog is hooked on this trace point */\n\t\t __bpf_trace_tick_stop()\n\t\t bpf_trace_run2()\n\t\t\t rcu_read_unlock_special()\n /* will send a IPI to itself */\n\t\t\t irq_work_queue_on(\u0026amp;rdp-\u0026gt;defer_qs_iw, rdp-\u0026gt;cpu);\n\nA simple reproducer can also be obtained by doing the following in\ntick_irq_exit(). It will hang on boot without the patch:\n\n static inline void tick_irq_exit(void)\n {\n +\trcu_read_lock();\n +\tWRITE_ONCE(current-\u0026gt;rcu_read_unlock_special.b.need_qs, true);\n +\trcu_read_unlock();\n +\n\n[neeraj: Apply Frederic\u0026apos;s suggested fix for PREEMPT_RT](CVE-2025-39744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special(). This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special(). In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield. This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Duplicate SPI Handling\n\nThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI\nNetlink message, which triggers the kernel function xfrm_alloc_spi().\nThis function is expected to ensure uniqueness of the Security Parameter\nIndex (SPI) for inbound Security Associations (SAs). However, it can\nreturn success even when the requested SPI is already in use, leading\nto duplicate SPIs assigned to multiple inbound SAs, differentiated\nonly by their destination addresses.\n\nThis behavior causes inconsistencies during SPI lookups for inbound packets.\nSince the lookup may return an arbitrary SA among those with the same SPI,\npacket processing can fail, resulting in packet drops.\n\nAccording to RFC 4301 section 4.4.2 , for inbound processing a unicast SA\nis uniquely identified by the SPI and optionally protocol.\n\nReproducing the Issue Reliably:\nTo consistently reproduce the problem, restrict the available SPI range in\ncharon.conf : spi_min = 0x10000000 spi_max = 0x10000002\nThis limits the system to only 2 usable SPI values.\nNext, create more than 2 Child SA. each using unique pair of src/dst address.\nAs soon as the 3rd Child SA is initiated, it will be assigned a duplicate\nSPI, since the SPI pool is already exhausted.\nWith a narrow SPI range, the issue is consistently reproducible.\nWith a broader/default range, it becomes rare and unpredictable.\n\nCurrent implementation:\nxfrm_spi_hash() lookup function computes hash using daddr, proto, and family.\nSo if two SAs have the same SPI but different destination addresses, then\nthey will:\na. Hash into different buckets\nb. Be stored in different linked lists (byspi + h)\nc. Not be seen in the same hlist_for_each_entry_rcu() iteration.\nAs a result, the lookup will result in NULL and kernel allows that Duplicate SPI\n\nProposed Change:\nxfrm_state_lookup_spi_proto() does a truly global search - across all states,\nregardless of hash bucket and matches SPI and proto.(CVE-2025-39797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().\n\nsyzbot reported the splat below. [0]\n\nWhen atmtcp_v_open() or atmtcp_v_close() is called via connect()\nor close(), atmtcp_send_control() is called to send an in-kernel\nspecial message.\n\nThe message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.\nAlso, a pointer of struct atm_vcc is set to atmtcp_control.vcc.\n\nThe notable thing is struct atmtcp_control is uAPI but has a\nspace for an in-kernel pointer.\n\n struct atmtcp_control {\n \tstruct atmtcp_hdr hdr;\t/* must be first */\n ...\n \tatm_kptr_t vcc;\t\t/* both directions */\n ...\n } __ATM_API_ALIGN;\n\n typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;\n\nThe special message is processed in atmtcp_recv_control() called\nfrom atmtcp_c_send().\n\natmtcp_c_send() is vcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send() and called from 2 paths:\n\n 1. .ndo_start_xmit() (vcc-\u0026gt;send() == atm_send_aal0())\n 2. vcc_sendmsg()\n\nThe problem is sendmsg() does not validate the message length and\nuserspace can abuse atmtcp_recv_control() to overwrite any kptr\nby atmtcp_control.\n\nLet\u0026apos;s add a new -\u0026gt;pre_send() hook to validate messages from sendmsg().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI\nKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]\nCPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]\nRIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297\nCode: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c\nRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203\nRAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c\nRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd\nR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000\nR13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff\nFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n ____sys_sendmsg+0x505/0x830 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f8d7e96a4a9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9\nRDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005\nRBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f\nR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac\nR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250\n \u0026lt;/TASK\u0026gt;\nModules linked in:(CVE-2025-39828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n CPU1 CPU2 (close())\n ---- ----\n sock_hold(sk) sock_hold(sk);\n lock_sock(sk) \u0026lt;-- block close()\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- refcnt by bt_accept_enqueue()\n release_sock(sk)\n lock_sock(sk)\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- last refcnt\n bt_accept_unlink(sk) \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-\u0026gt;cork.\n\nsyzbot reported the splat below. [0]\n\nThe repro does the following:\n\n 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)\n 2. Attach the prog to a SOCKMAP\n 3. Add a socket to the SOCKMAP\n 4. Activate fault injection\n 5. Send data less than cork_bytes\n\nAt 5., the data is carried over to the next sendmsg() as it is\nsmaller than the cork_bytes specified by bpf_msg_cork_bytes().\n\nThen, tcp_bpf_send_verdict() tries to allocate psock-\u0026gt;cork to hold\nthe data, but this fails silently due to fault injection + __GFP_NOWARN.\n\nIf the allocation fails, we need to revert the sk-\u0026gt;sk_forward_alloc\nchange done by sk_msg_alloc().\n\nLet\u0026apos;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate\npsock-\u0026gt;cork.\n\nThe \u0026quot;*copied\u0026quot; also needs to be updated such that a proper error can\nbe returned to the caller, sendmsg. It fails to allocate psock-\u0026gt;cork.\nNothing has been corked so far, so this patch simply sets \u0026quot;*copied\u0026quot;\nto 0.\n\n[0]:\nWARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983\nModules linked in:\nCPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156\nCode: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 \u0026lt;0f\u0026gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc\nRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246\nRAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80\nRDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000\nRBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4\nR10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380\nR13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872\nFS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __sk_destruct+0x86/0x660 net/core/sock.c:2339\n rcu_do_batch kernel/rcu/tree.c:2605 [inline]\n rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861\n handle_softirqs+0x286/0x870 kernel/softirq.c:579\n __do_softirq kernel/softirq.c:613 [inline]\n invoke_softirq kernel/softirq.c:453 [inline]\n __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:696\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup) | CPU 1 (delayed work callback)\ncnic_netdev_event() |\n cnic_stop_hw() | cnic_delete_task()\n cnic_cm_stop_bnx2x_hw() | ...\n cancel_delayed_work() | /* the queue_delayed_work()\n flush_workqueue() | executes after flush_workqueue()*/\n | queue_delayed_work()\n cnic_free_dev(dev)//free | cnic_delete_task() //new instance\n | dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays \u2014 such as inserting calls to ssleep()\nwithin the cnic_delete_task() function \u2014 to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: Defer ip_vs_ftp unregister during netns cleanup\n\nOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp\nbefore connections with valid cp-\u0026gt;app pointers are flushed, leading to a\nuse-after-free.\n\nFix this by introducing a global `exiting_module` flag, set to true in\nip_vs_ftp_exit() before unregistering the pernet subsystem. In\n__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns\ncleanup (when exiting_module is false) and defer it to\n__ip_vs_cleanup_batch(), which unregisters all apps after all connections\nare flushed. If called during module exit, unregister ip_vs_ftp\nimmediately.(CVE-2025-40018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete x-\u0026gt;tunnel as we delete x\n\nThe ipcomp fallback tunnels currently get deleted (from the various\nlists and hashtables) as the last user state that needed that fallback\nis destroyed (not deleted). If a reference to that user state still\nexists, the fallback state will remain on the hashtables/lists,\ntriggering the WARN in xfrm_state_fini. Because of those remaining\nreferences, the fix in commit f75a2804da39 (\u0026quot;xfrm: destroy xfrm_state\nsynchronously on net exit path\u0026quot;) is not complete.\n\nWe recently fixed one such situation in TCP due to defered freeing of\nskbs (commit 9b6412e6979f (\u0026quot;tcp: drop secpath at the same time as we\ncurrently drop dst\u0026quot;)). This can also happen due to IP reassembly: skbs\nwith a secpath remain on the reassembly queue until netns\ndestruction. If we can\u0026apos;t guarantee that the queues are flushed by the\ntime xfrm_state_fini runs, there may still be references to a (user)\nxfrm_state, preventing the timely deletion of the corresponding\nfallback state.\n\nInstead of chasing each instance of skbs holding a secpath one by one,\nthis patch fixes the issue directly within xfrm, by deleting the\nfallback state as soon as the last user state depending on it has been\ndeleted. Destruction will still happen when the final reference is\ndropped.\n\nA separate lockdep class for the fallback state is required since\nwe\u0026apos;re going to lock x-\u0026gt;tunnel while x is locked.(CVE-2025-40215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u0026gt;dev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026amp;proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026amp;proc_subdir_lock);\n [time window] | rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n | write_unlock(\u0026amp;proc_subdir_lock);\n read_lock(\u0026amp;proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)(CVE-2025-40271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_mon_reinit_self().\n\nsyzbot reported use-after-free of tipc_net(net)-\u0026gt;monitors[]\nin tipc_mon_reinit_self(). [0]\n\nThe array is protected by RTNL, but tipc_mon_reinit_self()\niterates over it without RTNL.\n\ntipc_mon_reinit_self() is called from tipc_net_finalize(),\nwhich is always under RTNL except for tipc_net_finalize_work().\n\nLet\u0026apos;s hold RTNL in tipc_net_finalize_work().\n\n[0]:\nBUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\nBUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\nRead of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989\n\nCPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025\nWorkqueue: events tipc_net_finalize_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568\n kasan_check_byte include/linux/kasan.h:399 [inline]\n lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\n rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline]\n rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline]\n rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244\n rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243\n write_lock_bh include/linux/rwlock_rt.h:99 [inline]\n tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718\n tipc_net_finalize+0x115/0x190 net/tipc/net.c:140\n process_one_work kernel/workqueue.c:3236 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400\n kthread+0x70e/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 6089:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657\n tipc_enable_bearer net/tipc/bearer.c:357 [inline]\n __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047\n __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline]\n tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393\n tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline]\n tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321\n genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:729\n ____sys_sendmsg+0x508/0x820 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/\n---truncated---(CVE-2025-40280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: use lock accessing port_state and rport state\n\nnvme_fc_unregister_remote removes the remote port on a lport object at\nany point in time when there is no active association. This races with\nwith the reconnect logic, because nvme_fc_create_association is not\ntaking a lock to check the port_state and atomically increase the\nactive count on the rport.(CVE-2025-40342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Fix incorrect error check in topology_parse_cpu_capacity()\n\nFix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()\nwhich causes the code to proceed with NULL clock pointers. The current\nlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both\nvalid pointers and NULL, leading to potential NULL pointer dereference\nin clk_get_rate().\n\nPer include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:\n\u0026quot;The error code within @ptr if it is an error pointer; 0 otherwise.\u0026quot;\n\nThis means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL\npointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)\nwhen cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be\ncalled when of_clk_get() returns NULL.\n\nReplace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid\npointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup\n\nRaw IP packets have no MAC header, leaving skb-\u0026gt;mac_header uninitialized.\nThis can trigger kernel panics on ARM64 when xfrm or other subsystems\naccess the offset due to strict alignment checks.\n\nInitialize the MAC header to prevent such crashes.\n\nThis can trigger kernel panics on ARM when running IPsec over the\nqmimux0 interface.\n\nExample trace:\n\n Internal error: Oops: 000000009600004f [#1] SMP\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1\n Hardware name: LS1028A RDB Board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : xfrm_input+0xde8/0x1318\n lr : xfrm_input+0x61c/0x1318\n sp : ffff800080003b20\n Call trace:\n xfrm_input+0xde8/0x1318\n xfrm6_rcv+0x38/0x44\n xfrm6_esp_rcv+0x48/0xa8\n ip6_protocol_deliver_rcu+0x94/0x4b0\n ip6_input_finish+0x44/0x70\n ip6_input+0x44/0xc0\n ipv6_rcv+0x6c/0x114\n __netif_receive_skb_one_core+0x5c/0x8c\n __netif_receive_skb+0x18/0x60\n process_backlog+0x78/0x17c\n __napi_poll+0x38/0x180\n net_rx_action+0x168/0x2f0(CVE-2025-68192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix potential use-after-free in have_mon_and_osd_map()\n\nThe wait loop in __ceph_open_session() can race with the client\nreceiving a new monmap or osdmap shortly after the initial map is\nreceived. Both ceph_monc_handle_map() and handle_one_map() install\na new map immediately after freeing the old one\n\n kfree(monc-\u0026gt;monmap);\n monc-\u0026gt;monmap = monmap;\n\n ceph_osdmap_destroy(osdc-\u0026gt;osdmap);\n osdc-\u0026gt;osdmap = newmap;\n\nunder client-\u0026gt;monc.mutex and client-\u0026gt;osdc.lock respectively, but\nbecause neither is taken in have_mon_and_osd_map() it\u0026apos;s possible for\nclient-\u0026gt;monc.monmap-\u0026gt;epoch and client-\u0026gt;osdc.osdmap-\u0026gt;epoch arms in\n\n client-\u0026gt;monc.monmap \u0026amp;\u0026amp; client-\u0026gt;monc.monmap-\u0026gt;epoch \u0026amp;\u0026amp;\n client-\u0026gt;osdc.osdmap \u0026amp;\u0026amp; client-\u0026gt;osdc.osdmap-\u0026gt;epoch;\n\ncondition to dereference an already freed map. This happens to be\nreproducible with generic/395 and generic/397 with KASAN enabled:\n\n BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70\n Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305\n CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n have_mon_and_osd_map+0x56/0x70\n ceph_open_session+0x182/0x290\n ceph_get_tree+0x333/0x680\n vfs_get_tree+0x49/0x180\n do_new_mount+0x1a3/0x2d0\n path_mount+0x6dd/0x730\n do_mount+0x99/0xe0\n __do_sys_mount+0x141/0x180\n do_syscall_64+0x9f/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 13305:\n ceph_osdmap_alloc+0x16/0x130\n ceph_osdc_init+0x27a/0x4c0\n ceph_create_client+0x153/0x190\n create_fs_client+0x50/0x2a0\n ceph_get_tree+0xff/0x680\n vfs_get_tree+0x49/0x180\n do_new_mount+0x1a3/0x2d0\n path_mount+0x6dd/0x730\n do_mount+0x99/0xe0\n __do_sys_mount+0x141/0x180\n do_syscall_64+0x9f/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Freed by task 9475:\n kfree+0x212/0x290\n handle_one_map+0x23c/0x3b0\n ceph_osdc_handle_map+0x3c9/0x590\n mon_dispatch+0x655/0x6f0\n ceph_con_process_message+0xc3/0xe0\n ceph_con_v1_try_read+0x614/0x760\n ceph_con_workfn+0x2de/0x650\n process_one_work+0x486/0x7c0\n process_scheduled_works+0x73/0x90\n worker_thread+0x1c8/0x2a0\n kthread+0x2ec/0x300\n ret_from_fork+0x24/0x40\n ret_from_fork_asm+0x1a/0x30\n\nRewrite the wait loop to check the above condition directly with\nclient-\u0026gt;monc.mutex and client-\u0026gt;osdc.lock taken as appropriate. While\nat it, improve the timeout handling (previously mount_timeout could be\nexceeded in case wait_event_interruptible_timeout() slept more than\nonce) and access client-\u0026gt;auth_err under client-\u0026gt;monc.mutex to match\nhow it\u0026apos;s set in finish_auth().\n\nmonmap_show() and osdmap_show() now take the respective lock before\naccessing the map as well.(CVE-2025-68285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()\n\nrlen value is a user-controlled value, but dtv5100_i2c_msg() does not\ncheck the size of the rlen value. Therefore, if it is set to a value\nlarger than sizeof(st-\u0026gt;data), an out-of-bounds vuln occurs for st-\u0026gt;data.\n\nTherefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cm: Fix leaking the multicast GID table reference\n\nIf the CM ID is destroyed while the CM event for multicast creating is\nstill queued the cancel_work_sync() will prevent the work from running\nwhich also prevents destroying the ah_attr. This leaks a refcount and\ntriggers a WARN:\n\n GID entry ref leak for dev syz1 index 2 ref=573\n WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]\n WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886\n\nDestroy the ah_attr after canceling the work, it is safe to call this\ntwice.(CVE-2025-71084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: fix check for port enabled in team_queue_override_port_prio_changed()\n\nThere has been a syzkaller bug reported recently with the following\ntrace:\n\nlist_del corruption, ffff888058bea080-\u0026gt;prev is LIST_POISON2 (dead000000000122)\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:59!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nCPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59\nCode: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 \u0026lt;0f\u0026gt; 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286\nRAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000\nRDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005\nRBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230\nR13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480\nFS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __list_del_entry_valid include/linux/list.h:132 [inline]\n __list_del_entry include/linux/list.h:223 [inline]\n list_del_rcu include/linux/rculist.h:178 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]\n team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]\n team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534\n team_option_set drivers/net/team/team_core.c:376 [inline]\n team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653\n genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684\n __sys_sendmsg+0x16d/0x220 net/socket.c:2716\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe problem is in this flow:\n1) Port is enabled, queue_id != 0, in qom_list\n2) Port gets disabled\n -\u0026gt; team_port_disable()\n -\u0026gt; team_queue_override_port_del()\n -\u0026gt; del (removed from list)\n3) Port is disabled, queue_id != 0, not in any list\n4) Priority changes\n -\u0026gt; team_queue_override_port_prio_changed()\n -\u0026gt; checks: port disabled \u0026amp;\u0026amp; queue_id != 0\n -\u0026gt; calls del - hits the BUG as it is removed already\n\nTo fix this, change the check in team_queue_override_port_prio_changed()\nso it returns early if port is not enabled.(CVE-2025-71091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf\n\nA zero length gss_token results in pages == 0 and in_token-\u0026gt;pages[0]\nis NULL. The code unconditionally evaluates\npage_address(in_token-\u0026gt;pages[0]) for the initial memcpy, which can\ndereference NULL even when the copy length is 0. Guard the first\nmemcpy so it only runs when length \u0026gt; 0.(CVE-2025-71120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\u0026quot;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\u0026quot;)\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command\u0026apos;s data structures (cmd-\u0026gt;req.sg and cmd-\u0026gt;iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT \u2192 both pointers NULL\n2. H2C_DATA PDU for READ command \u2192 cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n3. H2C_DATA PDU for uninitialized command slot \u2192 both pointers NULL\n\nThe fix validates both cmd-\u0026gt;req.sg and cmd-\u0026gt;iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n- WRITE commands: both allocated(CVE-2026-22998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()\n\nIn nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,\nthe function jumps to the out_scratch label without freeing the already\nallocated dsaddrs list, leading to a memory leak.\n\nFix this by jumping to the out_err_drain_dsaddrs label, which properly\nfrees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)",
"id": "OESA-2026-1341",
"modified": "2026-08-06T11:10:22Z",
"published": "2026-02-13T11:10:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1341"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50151"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53521"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53594"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37766"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37770"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38480"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38572"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38618"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39797"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23038"
}
],
"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-2022-49190",
"CVE-2022-49309",
"CVE-2022-49829",
"CVE-2022-50151",
"CVE-2022-50159",
"CVE-2022-50616",
"CVE-2022-50735",
"CVE-2023-52927",
"CVE-2023-53250",
"CVE-2023-53254",
"CVE-2023-53521",
"CVE-2023-53594",
"CVE-2023-53712",
"CVE-2023-53840",
"CVE-2023-54048",
"CVE-2023-54145",
"CVE-2023-54321",
"CVE-2024-53179",
"CVE-2025-21981",
"CVE-2025-23138",
"CVE-2025-37766",
"CVE-2025-37770",
"CVE-2025-37947",
"CVE-2025-38068",
"CVE-2025-38154",
"CVE-2025-38250",
"CVE-2025-38480",
"CVE-2025-38556",
"CVE-2025-38572",
"CVE-2025-38574",
"CVE-2025-38618",
"CVE-2025-38676",
"CVE-2025-38728",
"CVE-2025-39676",
"CVE-2025-39702",
"CVE-2025-39744",
"CVE-2025-39749",
"CVE-2025-39797",
"CVE-2025-39828",
"CVE-2025-39853",
"CVE-2025-39860",
"CVE-2025-39913",
"CVE-2025-39945",
"CVE-2025-40018",
"CVE-2025-40105",
"CVE-2025-40215",
"CVE-2025-40271",
"CVE-2025-40280",
"CVE-2025-40342",
"CVE-2025-40346",
"CVE-2025-68192",
"CVE-2025-68285",
"CVE-2025-68819",
"CVE-2025-71084",
"CVE-2025-71091",
"CVE-2025-71120",
"CVE-2026-22998",
"CVE-2026-23038"
]
}
OPENSUSE-SU-2025:20081-1
Vulnerability from csaf_opensuse - Published: 2025-11-25 07:35 - Updated: 2025-11-25 07:35RHSA-2026:3520
Vulnerability from csaf_opensuse - Published: 2026-03-02 00:00 - Updated: 2026-09-16 18:34RHSA-2026:27731
Vulnerability from csaf_redhat - Published: 2026-06-22 05:29 - Updated: 2026-09-16 18:29A flaw was found in the Linux kernel's BPF (Berkeley Packet Filter) sockmap subsystem. A race condition exists where the `sk_socket` is not properly locked or referenced during the `skb_send_sock()` function call, allowing for a use-after-free vulnerability. This can be exploited by a local attacker, leading to a system crash (Denial of Service) and potentially enabling information disclosure or privilege escalation.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.