Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-39851 (GCVE-0-2025-39851)
Vulnerability from cvelistv5 – Published: 2025-09-19 15:26 – Updated: 2026-08-05 12:05- CWE-476 - NULL Pointer Dereference
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
1274e1cc42264d4e629841e4f182795cb0becfd2 , < 4ff4f3104da6507e0f118c63c4560dfdeb59dce3
(git)
Affected: 1274e1cc42264d4e629841e4f182795cb0becfd2 , < 0e8630f24c14d9c655d19eabe2e52a9e9f713307 (git) Affected: 1274e1cc42264d4e629841e4f182795cb0becfd2 , < 6ead38147ebb813f08be6ea8ef547a0e4c09559a (git) |
guessed | |
| Linux | Linux |
Affected:
5.8
Unaffected: 0 , < 5.8 (semver) Unaffected: 6.12.46 , ≤ 6.12.* (semver) Unaffected: 6.16.6 , ≤ 6.16.* (semver) Unaffected: 6.17 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2025-39851",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-14T19:21:10.346641Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-476",
"description": "CWE-476 NULL Pointer Dereference",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-01-14T19:23:12.460Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4ff4f3104da6507e0f118c63c4560dfdeb59dce3",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "0e8630f24c14d9c655d19eabe2e52a9e9f713307",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "6ead38147ebb813f08be6ea8ef547a0e4c09559a",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.8"
},
{
"lessThan": "5.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.46",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.46",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.6",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "5.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u003cTASK\u003e\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.5,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:N - `vxlan_rcv` is the UDP tunnel `encap_rcv` handler, so a single crafted VXLAN datagram sent to the VTEP\u0027s UDP port from anywhere routable reaches `vxlan_set_mac` \u2192 `vxlan_snoop` with a fully attacker-chosen inner source MAC. VXLAN underlays are L3-routed, so the attacker is not confined to the local segment.\nAC:L - One unsolicited packet whose inner source MAC matches an nh-backed FDB entry triggers the NULL dereference deterministically \u2014 no race, no memory-layout grooming, no timing window. Learning is the kernel default for new VXLAN devices and nexthop-backed FDB entries are standard EVPN programming, so the required state is ordinary deployment configuration rather than a condition outside the attacker\u0027s control.\nPR:N - VXLAN carries no authentication and `vxlan_rcv` performs no source-address or peer validation before handing the inner frame to `vxlan_snoop`. An entirely unauthenticated off-box attacker needs no credentials or account on the target.\nUI:N - The crash happens during packet receive processing with no involvement from any local user or administrator. No victim action of any kind is required.\nS:U - The fault occurs in the kernel and its impact is confined to that same kernel\u0027s security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:N - The dereference is a read of `remote_ip` at offset 0 (and `remote_ifindex` nearby) from a NULL pointer, well inside the unmapped guard page, so no data is read or returned to the attacker. Nothing is disclosed before the fault aborts execution.\nI:N - Execution faults at the read in `vxlan_addr_equal()`, before the `rdst-\u003eremote_ip = *src_ip` assignment, so no write or state modification ever occurs. This is a pure NULL-pointer read with no corruption or control-flow primitive.\nA:H - The NULL dereference oopses in softirq/NAPI context, which takes the `in_interrupt()` path in `die()` and panics the machine (\"Fatal exception in interrupt\") rather than merely killing a task. A remote attacker can repeat the single triggering packet at will for a persistent whole-system denial of service."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:05:38.080Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4ff4f3104da6507e0f118c63c4560dfdeb59dce3"
},
{
"url": "https://git.kernel.org/stable/c/0e8630f24c14d9c655d19eabe2e52a9e9f713307"
},
{
"url": "https://git.kernel.org/stable/c/6ead38147ebb813f08be6ea8ef547a0e4c09559a"
}
],
"title": "vxlan: Fix NPD when refreshing an FDB entry with a nexthop object",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39851",
"datePublished": "2025-09-19T15:26:23.576Z",
"dateReserved": "2025-04-16T07:20:57.142Z",
"dateUpdated": "2026-08-05T12:05:38.080Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-39851",
"date": "2026-09-19",
"epss": "0.00293",
"percentile": "0.22178"
},
"microsoft_vex": {
"current_release_date": "2026-08-23T14:45:14.000Z",
"cve": "CVE-2025-39851",
"id": "msrc_CVE-2025-39851",
"initial_release_date": "2025-09-21T01:01:55.000Z",
"product_status:known_affected": "23",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "vxlan: Fix NPD when refreshing an FDB entry with a nexthop object",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-39851.json",
"version": "20"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4ff4f3104da6507e0f118c63c4560dfdeb59dce3",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "0e8630f24c14d9c655d19eabe2e52a9e9f713307",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "6ead38147ebb813f08be6ea8ef547a0e4c09559a",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.8"
},
{
"lessThan": "5.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.46",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2980C061-51F5-499C-B8BE-47E98D17CE4B",
"versionEndExcluding": "6.12.46",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "548F104C-0F08-438B-9C97-64C903F0C678",
"versionEndExcluding": "6.16.6",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*",
"matchCriteriaId": "327D22EF-390B-454C-BD31-2ED23C998A1C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*",
"matchCriteriaId": "C730CD9A-D969-4A8E-9522-162AAF7C0EE9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*",
"matchCriteriaId": "39982C4B-716E-4B2F-8196-FA301F47807D",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*",
"matchCriteriaId": "340BEEA9-D70D-4290-B502-FBB1032353B1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u003cTASK\u003e\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q"
}
],
"id": "CVE-2025-39851",
"lastModified": "2026-07-30T06:23:50.827",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-39851",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-14T19:21:10.346641Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-09-19T16:15:43.983",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0e8630f24c14d9c655d19eabe2e52a9e9f713307"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4ff4f3104da6507e0f118c63c4560dfdeb59dce3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6ead38147ebb813f08be6ea8ef547a0e4c09559a"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T01:23:34+00:00",
"cve": "CVE-2025-39851",
"id": "CVE-2025-39851",
"initial_release_date": "2025-09-19T00:00:00+00:00",
"product_status:known_affected": "184",
"product_status:known_not_affected": "90",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-39851.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2025-39851",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-14T19:21:10.346641Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-476",
"description": "CWE-476 NULL Pointer Dereference",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-01-14T19:21:03.840Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4ff4f3104da6507e0f118c63c4560dfdeb59dce3",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "0e8630f24c14d9c655d19eabe2e52a9e9f713307",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "6ead38147ebb813f08be6ea8ef547a0e4c09559a",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.8"
},
{
"lessThan": "5.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.46",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.46",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.6",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "5.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u003cTASK\u003e\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q"
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.5,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-07-30T05:58:02.861Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4ff4f3104da6507e0f118c63c4560dfdeb59dce3"
},
{
"url": "https://git.kernel.org/stable/c/0e8630f24c14d9c655d19eabe2e52a9e9f713307"
},
{
"url": "https://git.kernel.org/stable/c/6ead38147ebb813f08be6ea8ef547a0e4c09559a"
}
],
"title": "vxlan: Fix NPD when refreshing an FDB entry with a nexthop object",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39851",
"datePublished": "2025-09-19T15:26:23.576Z",
"dateReserved": "2025-04-16T07:20:57.142Z",
"dateUpdated": "2026-07-30T05:58:02.861Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2026-AVI-0397
Vulnerability from certfr_avis - Published: 2026-04-03 - Updated: 2026-04-03
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire, une élévation de privilèges et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.10",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2025-68234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68234"
},
{
"name": "CVE-2025-40166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40166"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-68230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68230"
},
{
"name": "CVE-2025-39992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39992"
},
{
"name": "CVE-2025-68324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68324"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-40156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40156"
},
{
"name": "CVE-2025-68342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68342"
},
{
"name": "CVE-2025-68374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68374"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2025-68373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68373"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-68749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68749"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-40008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40008"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-68292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68292"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-39902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39902"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-68741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68741"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-39948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39948"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-68380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68380"
},
{
"name": "CVE-2025-68359",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68359"
},
{
"name": "CVE-2026-23269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23269"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-39881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39881"
},
{
"name": "CVE-2025-68283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68283"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2021-47142",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47142"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23129"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2025-22106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22106"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40265"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2025-68297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68297"
},
{
"name": "CVE-2025-68299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68299"
},
{
"name": "CVE-2025-40221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40221"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2025-39811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39811"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40350"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-68334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68334"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-37860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37860"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2025-68231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68231"
},
{
"name": "CVE-2025-39950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39950"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2025-40107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40107"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2021-47254",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47254"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23268"
},
{
"name": "CVE-2025-39920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39920"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2025-39942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39942"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2025-68179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68179"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2025-68347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68347"
},
{
"name": "CVE-2025-40010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40010"
},
{
"name": "CVE-2025-39944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39944"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2025-68235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68235"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-39843",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39843"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2025-68738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68738"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-39899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39899"
},
{
"name": "CVE-2025-68754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68754"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2025-21833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21833"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2025-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2025-39857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39857"
},
{
"name": "CVE-2025-38709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38709"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39865"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-68306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68306"
},
{
"name": "CVE-2025-39877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39877"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2025-38502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38502"
},
{
"name": "CVE-2025-68300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68300"
},
{
"name": "CVE-2025-39886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39886"
},
{
"name": "CVE-2025-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68763"
},
{
"name": "CVE-2025-68294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68294"
},
{
"name": "CVE-2025-40290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40290"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2025-40249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40249"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-39823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39823"
},
{
"name": "CVE-2025-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68198"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-40013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40013"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2025-40169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40169"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2025-68218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68218"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2025-39927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39927"
},
{
"name": "CVE-2025-40024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40024"
},
{
"name": "CVE-2025-40238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40238"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2025-39842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39842"
},
{
"name": "CVE-2025-40047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40047"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2025-39815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39815"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2025-39849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39849"
},
{
"name": "CVE-2025-40033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40033"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2025-39894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39894"
},
{
"name": "CVE-2025-39861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39861"
},
{
"name": "CVE-2025-68215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68215"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-68228",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68228"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2025-62626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62626"
},
{
"name": "CVE-2025-39940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39940"
},
{
"name": "CVE-2025-68338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68338"
},
{
"name": "CVE-2025-68304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68304"
},
{
"name": "CVE-2025-68370",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68370"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2025-68180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68180"
},
{
"name": "CVE-2025-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68343"
},
{
"name": "CVE-2025-68726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68726"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-68748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68748"
},
{
"name": "CVE-2025-68223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68223"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-40292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40292"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-39981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39981"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2025-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38627"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2025-40218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40218"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-68237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68237"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2025-68259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68259"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-22058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22058"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-68356",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68356"
},
{
"name": "CVE-2025-40067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40067"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2025-40101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40101"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2025-40038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40038"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2025-39805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39805"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2024-46830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
},
{
"name": "CVE-2024-47666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47666"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-40176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40176"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2025-71128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71128"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-68222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68222"
},
{
"name": "CVE-2025-68743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68743"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2025-40201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40201"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2025-68232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68232"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2025-68348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68348"
},
{
"name": "CVE-2025-68744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68744"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2025-68320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68320"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2025-68376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68376"
},
{
"name": "CVE-2025-68172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68172"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2025-40165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40165"
},
{
"name": "CVE-2025-68341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68341"
},
{
"name": "CVE-2025-68296",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68296"
},
{
"name": "CVE-2025-68361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68361"
},
{
"name": "CVE-2025-40328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40328"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2025-39901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39901"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2025-68752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68752"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2025-40250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40250"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2025-40255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40255"
},
{
"name": "CVE-2025-40246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40246"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-40226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40226"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2025-68756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68756"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-68360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68360"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-39895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39895"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2025-39914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39914"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2025-39938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39938"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2025-39982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39982"
},
{
"name": "CVE-2025-40129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40129"
},
{
"name": "CVE-2025-39965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39965"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-39932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
},
{
"name": "CVE-2025-40301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40301"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2025-68298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68298"
},
{
"name": "CVE-2025-40207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40207"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-68747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68747"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-40266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40266"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-68739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68739"
},
{
"name": "CVE-2025-39916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39916"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-40079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40079"
},
{
"name": "CVE-2025-40260",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40260"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2022-49635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49635"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2025-39852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39852"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2025-40235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40235"
},
{
"name": "CVE-2025-39991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39991"
},
{
"name": "CVE-2025-68281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68281"
},
{
"name": "CVE-2025-68729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68729"
},
{
"name": "CVE-2025-68208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68208"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2025-68236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68236"
},
{
"name": "CVE-2025-68333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68333"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2025-40031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40031"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2025-40293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40293"
},
{
"name": "CVE-2025-68751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68751"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2025-68760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68760"
},
{
"name": "CVE-2025-68305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68305"
},
{
"name": "CVE-2025-68352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68352"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-40320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40320"
},
{
"name": "CVE-2025-39870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39870"
},
{
"name": "CVE-2025-40247",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40247"
},
{
"name": "CVE-2025-68375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68375"
},
{
"name": "CVE-2025-68753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68753"
},
{
"name": "CVE-2025-68369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68369"
},
{
"name": "CVE-2025-39807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39807"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-38236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38236"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-68329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68329"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2025-40215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40215"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-40155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40155"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-39961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39961"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2026-22984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22984"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2025-40329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40329"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-68766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68766"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-39891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39891"
},
{
"name": "CVE-2025-40059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40059"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-39897",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39897"
},
{
"name": "CVE-2025-68326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68326"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2025-39854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39854"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-68212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68212"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-68730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68730"
},
{
"name": "CVE-2025-68213",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68213"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-68233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68233"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-68225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68225"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2025-39678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39678"
},
{
"name": "CVE-2025-68219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68219"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2021-47145",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47145"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-40009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40009"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68323"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2025-68221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68221"
},
{
"name": "CVE-2025-39832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39832"
},
{
"name": "CVE-2025-40000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40000"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2025-68262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68262"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-68735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68735"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-39835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39835"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-39829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39829"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-39909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39909"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2025-68293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68293"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-40159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40159"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2025-39836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39836"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-68762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68762"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-04-03T00:00:00",
"last_revision_date": "2026-04-03T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0397",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-04-03T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-04-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8095-5",
"url": "https://ubuntu.com/security/notices/USN-8095-5"
},
{
"published_at": "2026-04-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8149-1",
"url": "https://ubuntu.com/security/notices/USN-8149-1"
},
{
"published_at": "2026-04-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8141-1",
"url": "https://ubuntu.com/security/notices/USN-8141-1"
},
{
"published_at": "2026-04-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8148-3",
"url": "https://ubuntu.com/security/notices/USN-8148-3"
},
{
"published_at": "2026-04-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8143-1",
"url": "https://ubuntu.com/security/notices/USN-8143-1"
},
{
"published_at": "2026-04-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8145-2",
"url": "https://ubuntu.com/security/notices/USN-8145-2"
},
{
"published_at": "2026-04-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8148-1",
"url": "https://ubuntu.com/security/notices/USN-8148-1"
},
{
"published_at": "2026-04-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8148-2",
"url": "https://ubuntu.com/security/notices/USN-8148-2"
},
{
"published_at": "2026-04-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8143-2",
"url": "https://ubuntu.com/security/notices/USN-8143-2"
},
{
"published_at": "2026-04-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8145-1",
"url": "https://ubuntu.com/security/notices/USN-8145-1"
},
{
"published_at": "2026-04-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8094-5",
"url": "https://ubuntu.com/security/notices/USN-8094-5"
},
{
"published_at": "2026-04-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8142-1",
"url": "https://ubuntu.com/security/notices/USN-8142-1"
}
]
}
CERTFR-2026-AVI-0421
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 d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
None| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.10",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"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-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2025-68234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68234"
},
{
"name": "CVE-2025-40166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40166"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-68230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68230"
},
{
"name": "CVE-2025-39992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39992"
},
{
"name": "CVE-2026-23202",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23202"
},
{
"name": "CVE-2025-68324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68324"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-40156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40156"
},
{
"name": "CVE-2025-68342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68342"
},
{
"name": "CVE-2025-68374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68374"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2025-68373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68373"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-68749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68749"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-40008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40008"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-68292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68292"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-39902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39902"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-68741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68741"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-39948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39948"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-68380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68380"
},
{
"name": "CVE-2025-68359",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68359"
},
{
"name": "CVE-2026-23269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23269"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-39881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39881"
},
{
"name": "CVE-2025-68283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68283"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23129"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2025-22106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22106"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2026-23020",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23020"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40265"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2025-68297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68297"
},
{
"name": "CVE-2025-68299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68299"
},
{
"name": "CVE-2025-40221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40221"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2025-39811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39811"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40350"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-68334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68334"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-37860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37860"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2025-68231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68231"
},
{
"name": "CVE-2025-39950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39950"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2025-40107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40107"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2026-23047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23047"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-68365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68365"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23268"
},
{
"name": "CVE-2025-39920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39920"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2025-39942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39942"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2025-68179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68179"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2025-68347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68347"
},
{
"name": "CVE-2025-40010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40010"
},
{
"name": "CVE-2025-39944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39944"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2025-68235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68235"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-39843",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39843"
},
{
"name": "CVE-2025-40202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40202"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2025-68738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68738"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23407"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-39899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39899"
},
{
"name": "CVE-2025-71080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71080"
},
{
"name": "CVE-2025-68754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68754"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2025-21833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21833"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2025-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2025-39857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39857"
},
{
"name": "CVE-2025-38709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38709"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39865"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-68306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68306"
},
{
"name": "CVE-2025-39877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39877"
},
{
"name": "CVE-2026-22991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22991"
},
{
"name": "CVE-2025-38502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38502"
},
{
"name": "CVE-2025-68300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68300"
},
{
"name": "CVE-2025-39886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39886"
},
{
"name": "CVE-2025-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68763"
},
{
"name": "CVE-2025-68294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68294"
},
{
"name": "CVE-2025-40290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40290"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2025-40249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40249"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-39823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39823"
},
{
"name": "CVE-2025-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68198"
},
{
"name": "CVE-2026-23408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23408"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-40013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40013"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2025-40169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40169"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2026-23207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23207"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2025-68218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68218"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2025-39927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39927"
},
{
"name": "CVE-2025-40024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40024"
},
{
"name": "CVE-2025-40238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40238"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2025-39842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39842"
},
{
"name": "CVE-2025-40047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40047"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-23406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23406"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2025-39815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39815"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2025-39849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39849"
},
{
"name": "CVE-2025-40033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40033"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2025-39894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39894"
},
{
"name": "CVE-2025-39861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39861"
},
{
"name": "CVE-2025-68215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68215"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-68228",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68228"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2025-62626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62626"
},
{
"name": "CVE-2025-39940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39940"
},
{
"name": "CVE-2025-68338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68338"
},
{
"name": "CVE-2025-68304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68304"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2025-68370",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68370"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2025-68180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68180"
},
{
"name": "CVE-2025-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68343"
},
{
"name": "CVE-2025-68726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68726"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2024-37354",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37354"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-68748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68748"
},
{
"name": "CVE-2025-68223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68223"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-40292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40292"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-39981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39981"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2025-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38627"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2025-68358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68358"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2025-40218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40218"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-68237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68237"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2025-68259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68259"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-22058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22058"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-68356",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68356"
},
{
"name": "CVE-2025-40067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40067"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2025-40101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40101"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-40038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40038"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2025-39805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39805"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-71180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71180"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2024-46830",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46830"
},
{
"name": "CVE-2024-47666",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47666"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-40176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40176"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2025-71128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71128"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-68222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68222"
},
{
"name": "CVE-2025-68743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68743"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2025-40201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40201"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2025-68232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68232"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2025-68348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68348"
},
{
"name": "CVE-2025-68744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68744"
},
{
"name": "CVE-2025-71182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71182"
},
{
"name": "CVE-2025-68320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68320"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2026-22990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22990"
},
{
"name": "CVE-2025-68376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68376"
},
{
"name": "CVE-2025-68172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68172"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2023-53041",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53041"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2025-40165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40165"
},
{
"name": "CVE-2025-68341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68341"
},
{
"name": "CVE-2025-68296",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68296"
},
{
"name": "CVE-2025-68361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68361"
},
{
"name": "CVE-2025-40328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40328"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2026-22978",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22978"
},
{
"name": "CVE-2025-39901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39901"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2025-68752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68752"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23410"
},
{
"name": "CVE-2025-40250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40250"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2025-40255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40255"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2025-40246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40246"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-40226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40226"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2025-68756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68756"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-68360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68360"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-39895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39895"
},
{
"name": "CVE-2023-54207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54207"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2025-39914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39914"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2025-39938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39938"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2025-39982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39982"
},
{
"name": "CVE-2025-40129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40129"
},
{
"name": "CVE-2025-39965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39965"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-39932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
},
{
"name": "CVE-2025-40301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40301"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2025-68298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68298"
},
{
"name": "CVE-2025-40207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40207"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-68747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68747"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-40266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40266"
},
{
"name": "CVE-2026-23091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23091"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-68739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68739"
},
{
"name": "CVE-2025-39916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39916"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-40079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40079"
},
{
"name": "CVE-2025-40260",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40260"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2022-49635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49635"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2026-23405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23405"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2026-23403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23403"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2025-39852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39852"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2025-40235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40235"
},
{
"name": "CVE-2025-39991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39991"
},
{
"name": "CVE-2025-68281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68281"
},
{
"name": "CVE-2025-68729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68729"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2025-68208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68208"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2025-68236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68236"
},
{
"name": "CVE-2025-68333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68333"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2025-40031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40031"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2025-40293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40293"
},
{
"name": "CVE-2025-68751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68751"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2026-22976",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22976"
},
{
"name": "CVE-2025-68760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68760"
},
{
"name": "CVE-2025-68305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68305"
},
{
"name": "CVE-2025-68352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68352"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-40320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40320"
},
{
"name": "CVE-2025-39870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39870"
},
{
"name": "CVE-2025-40247",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40247"
},
{
"name": "CVE-2025-68375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68375"
},
{
"name": "CVE-2025-68753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68753"
},
{
"name": "CVE-2025-68369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68369"
},
{
"name": "CVE-2025-39807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39807"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-38236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38236"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-68329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68329"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2025-40215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40215"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-40155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40155"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-39961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39961"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2026-23411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23411"
},
{
"name": "CVE-2026-22984",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22984"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2025-40329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40329"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-23409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23409"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-68766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68766"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-39891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39891"
},
{
"name": "CVE-2025-40059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40059"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-39897",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39897"
},
{
"name": "CVE-2025-68326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68326"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2026-23404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23404"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2025-39854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39854"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-68212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68212"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-68730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68730"
},
{
"name": "CVE-2025-68213",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68213"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-68233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68233"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-68817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68817"
},
{
"name": "CVE-2025-68225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68225"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2025-39678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39678"
},
{
"name": "CVE-2025-68219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68219"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-40009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40009"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68323"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2025-68221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68221"
},
{
"name": "CVE-2025-39832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39832"
},
{
"name": "CVE-2025-40000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40000"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2025-68262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68262"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-68735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68735"
},
{
"name": "CVE-2026-23021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23021"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-39835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39835"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2025-39829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39829"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-39909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39909"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2025-68293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68293"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-40159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40159"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2025-39836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39836"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-68762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68762"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-04-10T00:00:00",
"last_revision_date": "2026-04-10T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0421",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-04-10T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8164-1",
"url": "https://ubuntu.com/security/notices/USN-8164-1"
},
{
"published_at": "2026-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8149-2",
"url": "https://ubuntu.com/security/notices/USN-8149-2"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8159-3",
"url": "https://ubuntu.com/security/notices/USN-8159-3"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8159-1",
"url": "https://ubuntu.com/security/notices/USN-8159-1"
},
{
"published_at": "2026-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8145-4",
"url": "https://ubuntu.com/security/notices/USN-8145-4"
},
{
"published_at": "2026-04-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8159-2",
"url": "https://ubuntu.com/security/notices/USN-8159-2"
},
{
"published_at": "2026-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8165-1",
"url": "https://ubuntu.com/security/notices/USN-8165-1"
},
{
"published_at": "2026-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8163-1",
"url": "https://ubuntu.com/security/notices/USN-8163-1"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8145-3",
"url": "https://ubuntu.com/security/notices/USN-8145-3"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8152-1",
"url": "https://ubuntu.com/security/notices/USN-8152-1"
},
{
"published_at": "2026-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8148-5",
"url": "https://ubuntu.com/security/notices/USN-8148-5"
},
{
"published_at": "2026-04-06",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8148-4",
"url": "https://ubuntu.com/security/notices/USN-8148-4"
},
{
"published_at": "2026-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8162-1",
"url": "https://ubuntu.com/security/notices/USN-8162-1"
}
]
}
CERTFR-2026-AVI-0602
Vulnerability from certfr_avis - Published: 2026-05-15 - Updated: 2026-05-15
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-40166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40166"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-39992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39992"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2026-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23167"
},
{
"name": "CVE-2025-40156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40156"
},
{
"name": "CVE-2025-71065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71065"
},
{
"name": "CVE-2025-68342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68342"
},
{
"name": "CVE-2025-68374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68374"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-23098",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23098"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-68286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68286"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2025-71094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71094"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-40008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40008"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-68778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68778"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-40254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40254"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-39902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39902"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-68741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68741"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-68795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68795"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-39948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39948"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-68380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68380"
},
{
"name": "CVE-2026-23269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23269"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-39881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39881"
},
{
"name": "CVE-2023-2640",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2640"
},
{
"name": "CVE-2025-68283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68283"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-68339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68339"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-71071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71071"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-68295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68295"
},
{
"name": "CVE-2025-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23129"
},
{
"name": "CVE-2025-68728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68728"
},
{
"name": "CVE-2025-68364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68364"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-71087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71087"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2025-22106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22106"
},
{
"name": "CVE-2025-68287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68287"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-71135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71135"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-68746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68746"
},
{
"name": "CVE-2025-68773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68773"
},
{
"name": "CVE-2025-71133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71133"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2025-68796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68796"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-68220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68220"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-68302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68302"
},
{
"name": "CVE-2025-68238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68238"
},
{
"name": "CVE-2025-68297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68297"
},
{
"name": "CVE-2025-40221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40221"
},
{
"name": "CVE-2025-68804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68804"
},
{
"name": "CVE-2025-68769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68769"
},
{
"name": "CVE-2025-39811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39811"
},
{
"name": "CVE-2025-68794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68794"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40350"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-71088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71088"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2026-23090",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23090"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-68307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68307"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-37860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37860"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2025-68231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68231"
},
{
"name": "CVE-2025-39950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39950"
},
{
"name": "CVE-2026-23064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23064"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-68806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68806"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-40251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40251"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-71078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71078"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2025-40107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40107"
},
{
"name": "CVE-2025-71083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71083"
},
{
"name": "CVE-2026-23061",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23061"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-68813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68813"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-68365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68365"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2026-23119",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23119"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23268"
},
{
"name": "CVE-2025-39920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39920"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-68344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68344"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-71154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71154"
},
{
"name": "CVE-2022-49046",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49046"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2025-39942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39942"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2025-68179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68179"
},
{
"name": "CVE-2025-68229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68229"
},
{
"name": "CVE-2025-68257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68257"
},
{
"name": "CVE-2025-39929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39929"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2024-46816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46816"
},
{
"name": "CVE-2025-71084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71084"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2026-23049",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23049"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2025-68347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68347"
},
{
"name": "CVE-2025-40010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40010"
},
{
"name": "CVE-2025-39944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39944"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2025-68235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68235"
},
{
"name": "CVE-2025-68770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68770"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-39843",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39843"
},
{
"name": "CVE-2025-40202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40202"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-68780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68780"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-71081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71081"
},
{
"name": "CVE-2026-23101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23101"
},
{
"name": "CVE-2026-23407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23407"
},
{
"name": "CVE-2026-23099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23099"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-71121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71121"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2025-38022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38022"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-39899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39899"
},
{
"name": "CVE-2025-71080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71080"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2026-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23085"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2026-23209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23209"
},
{
"name": "CVE-2025-71136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71136"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-68354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68354"
},
{
"name": "CVE-2025-68801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68801"
},
{
"name": "CVE-2025-21833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21833"
},
{
"name": "CVE-2026-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23150"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2025-68258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68258"
},
{
"name": "CVE-2025-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2025-39857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39857"
},
{
"name": "CVE-2025-38709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38709"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39865"
},
{
"name": "CVE-2025-71138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71138"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-68291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68291"
},
{
"name": "CVE-2025-39877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39877"
},
{
"name": "CVE-2025-71122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71122"
},
{
"name": "CVE-2025-38502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38502"
},
{
"name": "CVE-2025-39886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39886"
},
{
"name": "CVE-2025-68763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68763"
},
{
"name": "CVE-2025-71144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71144"
},
{
"name": "CVE-2025-68308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68308"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-39823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39823"
},
{
"name": "CVE-2025-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68198"
},
{
"name": "CVE-2026-23408",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23408"
},
{
"name": "CVE-2025-38234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38234"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-40013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40013"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2025-40169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40169"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2025-40252",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40252"
},
{
"name": "CVE-2025-68218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68218"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68255"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2025-39927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39927"
},
{
"name": "CVE-2025-40024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40024"
},
{
"name": "CVE-2025-40238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40238"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2025-39842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39842"
},
{
"name": "CVE-2025-40047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40047"
},
{
"name": "CVE-2026-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23133"
},
{
"name": "CVE-2026-23406",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23406"
},
{
"name": "CVE-2025-71093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71093"
},
{
"name": "CVE-2025-71102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71102"
},
{
"name": "CVE-2026-23170",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23170"
},
{
"name": "CVE-2025-68759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68759"
},
{
"name": "CVE-2026-23273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23273"
},
{
"name": "CVE-2025-71188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71188"
},
{
"name": "CVE-2025-39815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39815"
},
{
"name": "CVE-2025-40345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40345"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2026-23125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23125"
},
{
"name": "CVE-2025-39849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39849"
},
{
"name": "CVE-2025-40033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40033"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-68733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68733"
},
{
"name": "CVE-2025-39894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39894"
},
{
"name": "CVE-2025-39861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39861"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-68335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68335"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2025-39940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39940"
},
{
"name": "CVE-2026-22997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22997"
},
{
"name": "CVE-2025-71153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71153"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2025-68330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68330"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2025-71196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71196"
},
{
"name": "CVE-2024-27388",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27388"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2025-68180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68180"
},
{
"name": "CVE-2025-68772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68772"
},
{
"name": "CVE-2025-68343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68343"
},
{
"name": "CVE-2024-57795",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57795"
},
{
"name": "CVE-2026-23078",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23078"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2025-71143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71143"
},
{
"name": "CVE-2025-68785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68785"
},
{
"name": "CVE-2025-71130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71130"
},
{
"name": "CVE-2025-68808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68808"
},
{
"name": "CVE-2025-68223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68223"
},
{
"name": "CVE-2025-68783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68783"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-40292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40292"
},
{
"name": "CVE-2025-71147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71147"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-39981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39981"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-23074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23074"
},
{
"name": "CVE-2025-71126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71126"
},
{
"name": "CVE-2025-68786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68786"
},
{
"name": "CVE-2025-71199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71199"
},
{
"name": "CVE-2023-32629",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32629"
},
{
"name": "CVE-2025-68797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68797"
},
{
"name": "CVE-2025-38627",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38627"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2025-40218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40218"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-68237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68237"
},
{
"name": "CVE-2025-40257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40257"
},
{
"name": "CVE-2025-68259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68259"
},
{
"name": "CVE-2025-71125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71125"
},
{
"name": "CVE-2025-71108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71108"
},
{
"name": "CVE-2025-71069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71069"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-68284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68284"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-40067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40067"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2025-40101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40101"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-40038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40038"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2025-39805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39805"
},
{
"name": "CVE-2025-68774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68774"
},
{
"name": "CVE-2025-40263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40263"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2026-23108",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23108"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-71194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71194"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-40176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40176"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2026-22999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22999"
},
{
"name": "CVE-2025-71082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71082"
},
{
"name": "CVE-2025-68222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68222"
},
{
"name": "CVE-2025-68765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68765"
},
{
"name": "CVE-2026-23089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23089"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-71132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71132"
},
{
"name": "CVE-2026-23071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23071"
},
{
"name": "CVE-2026-23056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23056"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2025-71077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71077"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-68328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68328"
},
{
"name": "CVE-2025-40201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40201"
},
{
"name": "CVE-2025-71140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71140"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2026-23063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23063"
},
{
"name": "CVE-2026-23073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23073"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2026-23058",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23058"
},
{
"name": "CVE-2025-71067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71067"
},
{
"name": "CVE-2025-68744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68744"
},
{
"name": "CVE-2025-68320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68320"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2025-71151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71151"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2025-68172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68172"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2025-68821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68821"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2026-23128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23128"
},
{
"name": "CVE-2025-68325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68325"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-71089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71089"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2025-40165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40165"
},
{
"name": "CVE-2025-40328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40328"
},
{
"name": "CVE-2025-68332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68332"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2025-39901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39901"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-68378",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68378"
},
{
"name": "CVE-2025-71141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71141"
},
{
"name": "CVE-2026-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23146"
},
{
"name": "CVE-2026-23037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23037"
},
{
"name": "CVE-2026-23410",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23410"
},
{
"name": "CVE-2025-40250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40250"
},
{
"name": "CVE-2025-71101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71101"
},
{
"name": "CVE-2025-40264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40264"
},
{
"name": "CVE-2026-23001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23001"
},
{
"name": "CVE-2025-68367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68367"
},
{
"name": "CVE-2025-40226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40226"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2025-68756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68756"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-39895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39895"
},
{
"name": "CVE-2023-54207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54207"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-68740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68740"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2025-39914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39914"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2025-68379",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68379"
},
{
"name": "CVE-2025-68256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68256"
},
{
"name": "CVE-2025-68777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68777"
},
{
"name": "CVE-2025-68254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68254"
},
{
"name": "CVE-2025-39938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39938"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2025-39982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39982"
},
{
"name": "CVE-2025-40129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40129"
},
{
"name": "CVE-2025-39965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39965"
},
{
"name": "CVE-2025-38556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38556"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-39932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39932"
},
{
"name": "CVE-2025-40301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40301"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2025-71109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71109"
},
{
"name": "CVE-2025-40207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40207"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-71118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71118"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2025-68327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68327"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-71150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71150"
},
{
"name": "CVE-2025-40266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40266"
},
{
"name": "CVE-2026-23091",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23091"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2026-23121",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23121"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2025-71066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71066"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2025-68799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68799"
},
{
"name": "CVE-2025-68345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68345"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-68288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68288"
},
{
"name": "CVE-2025-39916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39916"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-71107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71107"
},
{
"name": "CVE-2025-40079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40079"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2025-40083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40083"
},
{
"name": "CVE-2025-71111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71111"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-68811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68811"
},
{
"name": "CVE-2026-23096",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23096"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2026-23405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23405"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2026-23403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23403"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2025-39852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39852"
},
{
"name": "CVE-2026-23164",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23164"
},
{
"name": "CVE-2025-71116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71116"
},
{
"name": "CVE-2025-40235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40235"
},
{
"name": "CVE-2025-39991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39991"
},
{
"name": "CVE-2026-23124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23124"
},
{
"name": "CVE-2025-68208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68208"
},
{
"name": "CVE-2025-68362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68362"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-68290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68290"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-23075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23075"
},
{
"name": "CVE-2026-23120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23120"
},
{
"name": "CVE-2025-40031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40031"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2025-40293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40293"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-68331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68331"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2026-23105",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23105"
},
{
"name": "CVE-2025-68305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68305"
},
{
"name": "CVE-2025-68214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68214"
},
{
"name": "CVE-2025-40320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40320"
},
{
"name": "CVE-2025-39870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39870"
},
{
"name": "CVE-2025-68753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68753"
},
{
"name": "CVE-2025-68369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68369"
},
{
"name": "CVE-2025-39807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39807"
},
{
"name": "CVE-2025-68775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68775"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-71148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71148"
},
{
"name": "CVE-2025-68366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68366"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2024-36347",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36347"
},
{
"name": "CVE-2025-68815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68815"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-68346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68346"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-40155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40155"
},
{
"name": "CVE-2025-71096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71096"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2025-71105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71105"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2025-68771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68771"
},
{
"name": "CVE-2025-39961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39961"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2025-40248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40248"
},
{
"name": "CVE-2026-23411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23411"
},
{
"name": "CVE-2025-68303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68303"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-40259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40259"
},
{
"name": "CVE-2025-68757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68757"
},
{
"name": "CVE-2025-71068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71068"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2025-40329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40329"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2026-23033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23033"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-23409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23409"
},
{
"name": "CVE-2026-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23145"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-68766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68766"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2026-23076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23076"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-39891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39891"
},
{
"name": "CVE-2025-40059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40059"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-71123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71123"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2025-68372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68372"
},
{
"name": "CVE-2026-23404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23404"
},
{
"name": "CVE-2026-23112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23112"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2025-71137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71137"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2025-68301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68301"
},
{
"name": "CVE-2025-39854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39854"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-68217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68217"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-68289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68289"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-40253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40253"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-68213",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68213"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-68809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68809"
},
{
"name": "CVE-2025-68233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68233"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68282"
},
{
"name": "CVE-2025-68817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68817"
},
{
"name": "CVE-2025-71119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71119"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-68758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68758"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2025-71127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
},
{
"name": "CVE-2026-22998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22998"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-68340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68340"
},
{
"name": "CVE-2025-39678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39678"
},
{
"name": "CVE-2025-68219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68219"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-40258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40258"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-40325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40325"
},
{
"name": "CVE-2025-40009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40009"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2025-68336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68336"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68810"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2026-23097",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23097"
},
{
"name": "CVE-2025-39832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39832"
},
{
"name": "CVE-2025-40000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40000"
},
{
"name": "CVE-2025-40262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40262"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-68819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68819"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2025-38643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38643"
},
{
"name": "CVE-2025-71072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71072"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2025-68732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68732"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-39835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39835"
},
{
"name": "CVE-2025-68285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68285"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2026-23093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23093"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2025-39829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39829"
},
{
"name": "CVE-2025-71091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71091"
},
{
"name": "CVE-2025-39909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39909"
},
{
"name": "CVE-2025-68227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68227"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-68263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68263"
},
{
"name": "CVE-2025-68800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68800"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2025-68755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68755"
},
{
"name": "CVE-2025-71149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71149"
},
{
"name": "CVE-2025-68767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68767"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-40159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40159"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68727"
},
{
"name": "CVE-2026-23080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23080"
},
{
"name": "CVE-2025-39836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39836"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-05-15T00:00:00",
"last_revision_date": "2026-05-15T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0602",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-05-15T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"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 d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8261-1",
"url": "https://ubuntu.com/security/notices/USN-8261-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8266-1",
"url": "https://ubuntu.com/security/notices/USN-8266-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8180-6",
"url": "https://ubuntu.com/security/notices/USN-8180-6"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8254-2",
"url": "https://ubuntu.com/security/notices/USN-8254-2"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8265-1",
"url": "https://ubuntu.com/security/notices/USN-8265-1"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8260-1",
"url": "https://ubuntu.com/security/notices/USN-8260-1"
},
{
"published_at": "2026-05-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8258-1",
"url": "https://ubuntu.com/security/notices/USN-8258-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8267-1",
"url": "https://ubuntu.com/security/notices/USN-8267-1"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8200-3",
"url": "https://ubuntu.com/security/notices/USN-8200-3"
},
{
"published_at": "2026-05-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8255-2",
"url": "https://ubuntu.com/security/notices/USN-8255-2"
}
]
}
FKIE_CVE-2025-39851
Vulnerability from fkie_nvd - Published: 2025-09-19 16:15 - Updated: 2026-07-30 06:235.5 (Medium) - CVSS:3.1/
5.5 (Medium) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.17 | |
| linux | linux_kernel | 6.17 | |
| linux | linux_kernel | 6.17 | |
| linux | linux_kernel | 6.17 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4ff4f3104da6507e0f118c63c4560dfdeb59dce3",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "0e8630f24c14d9c655d19eabe2e52a9e9f713307",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
},
{
"lessThan": "6ead38147ebb813f08be6ea8ef547a0e4c09559a",
"status": "affected",
"version": "1274e1cc42264d4e629841e4f182795cb0becfd2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/vxlan/vxlan_core.c",
"drivers/net/vxlan/vxlan_private.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.8"
},
{
"lessThan": "5.8",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.46",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2980C061-51F5-499C-B8BE-47E98D17CE4B",
"versionEndExcluding": "6.12.46",
"versionStartIncluding": "5.8",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "548F104C-0F08-438B-9C97-64C903F0C678",
"versionEndExcluding": "6.16.6",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*",
"matchCriteriaId": "327D22EF-390B-454C-BD31-2ED23C998A1C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*",
"matchCriteriaId": "C730CD9A-D969-4A8E-9522-162AAF7C0EE9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*",
"matchCriteriaId": "39982C4B-716E-4B2F-8196-FA301F47807D",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*",
"matchCriteriaId": "340BEEA9-D70D-4290-B502-FBB1032353B1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u003cTASK\u003e\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q"
}
],
"id": "CVE-2025-39851",
"lastModified": "2026-07-30T06:23:50.827",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-39851",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-14T19:21:10.346641Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-09-19T16:15:43.983",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0e8630f24c14d9c655d19eabe2e52a9e9f713307"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4ff4f3104da6507e0f118c63c4560dfdeb59dce3"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6ead38147ebb813f08be6ea8ef547a0e4c09559a"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-MHRJ-PFXM-4X9V
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-12-12 21:31In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q
{
"affected": [],
"aliases": [
"CVE-2025-39851"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-19T16:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u003cTASK\u003e\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q",
"id": "GHSA-mhrj-pfxm-4x9v",
"modified": "2025-12-12T21:31:32Z",
"published": "2025-09-22T21:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e8630f24c14d9c655d19eabe2e52a9e9f713307"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4ff4f3104da6507e0f118c63c4560dfdeb59dce3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ead38147ebb813f08be6ea8ef547a0e4c09559a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2025-39851
Vulnerability from csaf_microsoft - Published: 2025-09-21 01:01 - Updated: 2026-08-23 14:45OESA-2025-2465 (CVE-2024-56591)
Vulnerability from osv_openeuler – Published: 2025-10-17 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
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)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"perf-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.104.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"perf-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.104.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-112.0.0.104.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\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\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\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2465",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
OESA-2025-2466 (CVE-2024-56591)
Vulnerability from osv_openeuler – Published: 2025-10-17 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
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)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"perf-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.115.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"perf-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.115.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-112.0.0.115.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\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\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\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2466",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
OESA-2025-2467 (CVE-2024-56591)
Vulnerability from osv_openeuler – Published: 2025-10-17 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
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)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"perf-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.118.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"perf-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.118.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-112.0.0.118.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\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\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\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2467",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2467"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
OESA-2025-2800 (CVE-2023-53091)
Vulnerability from osv_openeuler – Published: 2025-12-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix nexthop hash size
The nexthop code expects a 31 bit hash, such as what is returned by fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash returned by skb_get_hash() can lead to problems related to the fact that 'int hash' is a negative number when the MSB is set.
In the case of hash threshold nexthop groups, nexthop_select_path_hthr() will disproportionately select the first nexthop group entry. In the case of resilient nexthop groups, nexthop_select_path_res() may do an out of bounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535
which leads to the following panic:
BUG: unable to handle page fault for address: ffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:nexthop_select_path+0x197/0xbf0 Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP: 0018:ffff88810c36f260 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfxdevqueue_xmit+0x10/0x10 ? pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60
---truncated---(CVE-2023-53192)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)
In the Linux kernel, the following vulnerability has been resolved:
start_kernel: Add __no_stack_protector function attribute
Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.
Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.(CVE-2023-53491)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without hci_conn_get, so disconn_cfm must be called so they can clean up their conn, otherwise use-after-free occurs.
ISO:
iso_sock_connect:880: sk 00000000eabd6557 iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073 hci_dev_put:1487: hci0 orig refcnt 17 __iso_chan_add:214: conn 00000000b6251073 iso_sock_clear_timer:117: sock 00000000eabd6557 state 3 ... hci_rx_work:4085: hci0 Event packet hci_event_packet:7601: hci0: event 0x0f hci_cmd_status_evt:4346: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3107: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560 hci_conn_unlink:1102: hci0: hcon 000000001696f1fd hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2 hci_chan_list_flush:2780: hcon 000000001696f1fd hci_dev_put:1487: hci0 orig refcnt 21 hci_dev_put:1487: hci0 orig refcnt 20 hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c ... <no iso_* activity on sk/conn> ... iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth ==========================================================
L2CAP:
hci_cmd_status_evt:4359: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3085: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585 hci_conn_unlink:1102: hci0: hcon ffff88800c999000 hci_chan_list_flush:2780: hcon ffff88800c999000 hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfxlockacquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfxlockacquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)
In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)
In the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe & cheap. Thirdly, if dirtythresholds are larger than 1<<32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)
In the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang:
- Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do:
vhost_vq_set_backend(vq, vs_tpg); ...
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via:
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If a scsi request is then sent we do:
vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend
which sees the vs_tpg we just did a kfree on.
- Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg.
Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
- Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs.
Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.(CVE-2025-22083)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(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:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfxdquotinitialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
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:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _bpfget_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfget_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 __bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting:
cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)
In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.(CVE-2025-40139)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-294.0.0.196.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.(CVE-2023-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix nexthop hash size\n\nThe nexthop code expects a 31 bit hash, such as what is returned by\nfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash\nreturned by skb_get_hash() can lead to problems related to the fact that\n\u0026apos;int hash\u0026apos; is a negative number when the MSB is set.\n\nIn the case of hash threshold nexthop groups, nexthop_select_path_hthr()\nwill disproportionately select the first nexthop group entry. In the case\nof resilient nexthop groups, nexthop_select_path_res() may do an out of\nbounds access in nh_buckets[], for example:\n hash = -912054133\n num_nh_buckets = 2\n bucket_index = 65535\n\nwhich leads to the following panic:\n\nBUG: unable to handle page fault for address: ffffc900025910c8\nPGD 100000067 P4D 100000067 PUD 10026b067 PMD 0\nOops: 0002 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nWorkqueue: ipv6_addrconf addrconf_dad_work\nRIP: 0010:nexthop_select_path+0x197/0xbf0\nCode: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff \u0026lt;4d\u0026gt; 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85\nRSP: 0018:ffff88810c36f260 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8\nRBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219\nR10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0\nR13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900\nFS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x1ee/0x5c0\n ? __pfx_is_prefetch.constprop.0+0x10/0x10\n ? __pfx_page_fault_oops+0x10/0x10\n ? search_bpf_extables+0xfe/0x1c0\n ? fixup_exception+0x3b/0x470\n ? exc_page_fault+0xf6/0x110\n ? asm_exc_page_fault+0x26/0x30\n ? nexthop_select_path+0x197/0xbf0\n ? nexthop_select_path+0x197/0xbf0\n ? lock_is_held_type+0xe7/0x140\n vxlan_xmit+0x5b2/0x2340\n ? __lock_acquire+0x92b/0x3370\n ? __pfx_vxlan_xmit+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_register_lock_class+0x10/0x10\n ? skb_network_protocol+0xce/0x2d0\n ? dev_hard_start_xmit+0xca/0x350\n ? __pfx_vxlan_xmit+0x10/0x10\n dev_hard_start_xmit+0xca/0x350\n __dev_queue_xmit+0x513/0x1e20\n ? __pfx___dev_queue_xmit+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? mark_held_locks+0x44/0x90\n ? skb_push+0x4c/0x80\n ? eth_header+0x81/0xe0\n ? __pfx_eth_header+0x10/0x10\n ? neigh_resolve_output+0x215/0x310\n ? ip6_finish_output2+0x2ba/0xc90\n ip6_finish_output2+0x2ba/0xc90\n ? lock_release+0x236/0x3e0\n ? ip6_mtu+0xbb/0x240\n ? __pfx_ip6_finish_output2+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? lock_is_held_type+0xe7/0x140\n ip6_finish_output+0x1ee/0x780\n ip6_output+0x138/0x460\n ? __pfx_ip6_output+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_ip6_finish_output+0x10/0x10\n NF_HOOK.constprop.0+0xc0/0x420\n ? __pfx_NF_HOOK.constprop.0+0x10/0x10\n ? ndisc_send_skb+0x2c0/0x960\n ? __pfx_lock_release+0x10/0x10\n ? __local_bh_enable_ip+0x93/0x110\n ? lock_is_held_type+0xe7/0x140\n ndisc_send_skb+0x4be/0x960\n ? __pfx_ndisc_send_skb+0x10/0x10\n ? mark_held_locks+0x65/0x90\n ? find_held_lock+0x83/0xa0\n ndisc_send_ns+0xb0/0x110\n ? __pfx_ndisc_send_ns+0x10/0x10\n addrconf_dad_work+0x631/0x8e0\n ? lock_acquire+0x180/0x3f0\n ? __pfx_addrconf_dad_work+0x10/0x10\n ? mark_held_locks+0x24/0x90\n process_one_work+0x582/0x9c0\n ? __pfx_process_one_work+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? mark_held_locks+0x24/0x90\n worker_thread+0x93/0x630\n ? __kthread_parkme+0xdc/0x100\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x1a5/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n \n---truncated---(CVE-2023-53192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write\n\nDuring the sysfs firmware write process, a use-after-free read warning is\nlogged from the lpfc_wr_object() routine:\n\n BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]\n Use-after-free read at 0x0000000000cf164d (in kfence-#111):\n lpfc_wr_object+0x235/0x310 [lpfc]\n lpfc_write_firmware.cold+0x206/0x30d [lpfc]\n lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]\n lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]\n kernfs_fop_write_iter+0x121/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1ef/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x59/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe driver accessed wr_object pointer data, which was initialized into\nmailbox payload memory, after the mailbox object was released back to the\nmailbox pool.\n\nFix by moving the mailbox free calls to the end of the routine ensuring\nthat we don\u0026apos;t reference internal mailbox memory after release.(CVE-2023-53282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 (\u0026quot;x86: Fix early boot crash on gcc-10, third try\u0026quot;)\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let\u0026apos;s start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they\u0026apos;re compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.(CVE-2023-53491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere\u0026apos;s the call trace:\n \u0026lt;4\u0026gt;[102152.653246] Call Trace:\n \u0026lt;4\u0026gt;[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n \u0026lt;4\u0026gt;[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n \u0026lt;4\u0026gt;[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n \u0026lt;4\u0026gt;[102152.653268] notifier_call_chain+0x43/0x6b\n \u0026lt;4\u0026gt;[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n \u0026lt;4\u0026gt;[102152.653273] __pm_notifier_call_chain+0x22/0x39\n \u0026lt;4\u0026gt;[102152.653276] pm_suspend+0x287/0x57c\n \u0026lt;4\u0026gt;[102152.653278] state_store+0xae/0xe5\n \u0026lt;4\u0026gt;[102152.653281] kernfs_fop_write+0x109/0x173\n \u0026lt;4\u0026gt;[102152.653284] __vfs_write+0x16f/0x1a2\n \u0026lt;4\u0026gt;[102152.653287] ? selinux_file_permission+0xca/0x16f\n \u0026lt;4\u0026gt;[102152.653289] ? security_file_permission+0x36/0x109\n \u0026lt;4\u0026gt;[102152.653291] vfs_write+0x114/0x21d\n \u0026lt;4\u0026gt;[102152.653293] __x64_sys_write+0x7b/0xdb\n \u0026lt;4\u0026gt;[102152.653296] do_syscall_64+0x59/0x194\n \u0026lt;4\u0026gt;[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.(CVE-2023-53520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -\u0026gt; 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... \u0026lt;no iso_* activity on sk/conn\u0026gt; ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---(CVE-2023-53673)\n\nIn the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)\n\nIn the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh \u0026gt;= 1\u0026lt;\u0026lt;32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe \u0026amp; cheap. Thirdly, if dirtythresholds are larger than 1\u0026lt;\u0026lt;32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)\n\nIn the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u0026gt; vhost_scsi_get_req -\u0026gt; vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u0026gt;vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u0026gt;vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u0026gt;vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0026apos;t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0026apos;t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u0026gt;vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0026apos;s\nname and we will only match that target\u0026apos;s tpgs when we loop over the\nvs-\u0026gt;vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0026apos;s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\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\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n tc qdisc add dev lo root handle 1: drr\n tc filter add dev lo parent 1: basic classid 1:1\n tc class add dev lo parent 1: classid 1:1 drr\n tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n tc qdisc add dev lo parent 2:1 handle 3: netem\n tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n tc class delete dev lo classid 1:1\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n cifs_oplock_break()\n _cifsFileInfo_put(cfile)\n cifsFileInfo_put_final()\n cifs_sb_deactive()\n [last ref, start releasing sb]\n kill_sb()\n kill_anon_super()\n generic_shutdown_super()\n evict_inodes()\n dispose_list()\n evict()\n destroy_inode()\n call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- OK\n [later] i_callback()\n cifs_free_inode()\n kmem_cache_free(cinode)\n spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- UAF\n cifs_done_oplock_break(cinode) \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0026apos;t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0026apos;ve been\nthrown away by the eventual reset of the vCPU\u0026apos;s state.(CVE-2025-40102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)",
"id": "OESA-2025-2800",
"modified": "2026-08-06T11:09:55Z",
"published": "2025-12-12T11:09:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
}
],
"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-2023-53091",
"CVE-2023-53192",
"CVE-2023-53282",
"CVE-2023-53491",
"CVE-2023-53520",
"CVE-2023-53673",
"CVE-2024-38662",
"CVE-2024-42102",
"CVE-2024-49875",
"CVE-2024-57907",
"CVE-2024-57911",
"CVE-2024-58034",
"CVE-2025-21905",
"CVE-2025-22020",
"CVE-2025-22022",
"CVE-2025-22039",
"CVE-2025-22083",
"CVE-2025-23150",
"CVE-2025-23158",
"CVE-2025-37749",
"CVE-2025-37785",
"CVE-2025-37789",
"CVE-2025-37927",
"CVE-2025-38201",
"CVE-2025-38285",
"CVE-2025-38350",
"CVE-2025-38527",
"CVE-2025-38617",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38729",
"CVE-2025-39851",
"CVE-2025-40102",
"CVE-2025-40139"
]
}
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.