Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-39998 (GCVE-0-2025-39998)
Vulnerability from cvelistv5 – Published: 2025-10-15 07:58 – Updated: 2026-08-05 12:07| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < e6eeee5dc0d9221ff96d1b229b1d0222c8871b84
(git)
Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < 764a91e2fc9639e07aac93bc70e387e6b1e33084 (git) Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < ddc79fba132b807ff775467acceaf48b456e008b (git) Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4 (git) Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < f03aa5e39da7d045615b3951d2a6ca1d7132f881 (git) Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < 53c6351597e6a17ec6619f6f060d54128cb9a187 (git) Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < 4b292286949588bd2818e66ff102db278de8dd26 (git) Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < a150275831b765b0f1de8b8ff52ec5c6933ac15d (git) Affected: c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5 , < 27e06650a5eafe832a90fd2604f0c5e920857fae (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.38
Unaffected: 0 , < 2.6.38 (semver) Unaffected: 5.4.301 , ≤ 5.4.* (semver) Unaffected: 5.10.246 , ≤ 5.10.* (semver) Unaffected: 5.15.195 , ≤ 5.15.* (semver) Unaffected: 6.1.156 , ≤ 6.1.* (semver) Unaffected: 6.6.110 , ≤ 6.6.* (semver) Unaffected: 6.12.51 , ≤ 6.12.* (semver) Unaffected: 6.16.11 , ≤ 6.16.* (semver) Unaffected: 6.17.1 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/target/target_core_configfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "e6eeee5dc0d9221ff96d1b229b1d0222c8871b84",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "764a91e2fc9639e07aac93bc70e387e6b1e33084",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "ddc79fba132b807ff775467acceaf48b456e008b",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "f03aa5e39da7d045615b3951d2a6ca1d7132f881",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "53c6351597e6a17ec6619f6f060d54128cb9a187",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "4b292286949588bd2818e66ff102db278de8dd26",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "a150275831b765b0f1de8b8ff52ec5c6933ac15d",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "27e06650a5eafe832a90fd2604f0c5e920857fae",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/target/target_core_configfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.38"
},
{
"lessThan": "2.6.38",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.301",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.246",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.195",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.156",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.110",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.51",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.301",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.246",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.195",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.156",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.110",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.51",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.11",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17.1",
"versionStartIncluding": "2.6.38",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18",
"versionStartIncluding": "2.6.38",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: target_core_configfs: Add length check to avoid buffer overflow\n\nA buffer overflow arises from the usage of snprintf to write into the\nbuffer \"buf\" in target_lu_gp_members_show function located in\n/drivers/target/target_core_configfs.c. This buffer is allocated with\nsize LU_GROUP_NAME_BUF (256 bytes).\n\nsnprintf(...) formats multiple strings into buf with the HBA name\n(hba-\u003ehba_group.cg_item), a slash character, a devicename (dev-\u003e\ndev_group.cg_item) and a newline character, the total formatted string\nlength may exceed the buffer size of 256 bytes.\n\nSince snprintf() returns the total number of bytes that would have been\nwritten (the length of %s/%sn ), this value may exceed the buffer length\n(256 bytes) passed to memcpy(), this will ultimately cause function\nmemcpy reporting a buffer overflow error.\n\nAn additional check of the return value of snprintf() can avoid this\nbuffer overflow."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerability is triggered by read(2) on a configfs attribute file at /sys/kernel/config/target/core/alua/lu_gps/\u003cgp\u003e/members, which requires local access to the system. There is no network-facing path into target_lu_gp_members_show().\nAC:L - The over-read is fully deterministic \u2014 once an HBA+device name pair exceeding 255 combined characters exists, every read of the members file executes memcpy() with a length larger than the 256-byte stack source, with no race or memory-layout dependency.\nPR:L - The members attribute is CONFIGFS_ATTR_RO (mode 0444) under 0755 configfs directories, so any unprivileged local account \u2014 or a container with /sys bind-mounted read-only \u2014 can perform the triggering read; only the pre-existing long backstore name is admin-created state, not a privilege the attacker must hold.\nUI:N - Exploitation is a single read() by the attacker with no victim action required. No administrator or other user must be induced to do anything at exploit time.\nS:U - The out-of-bounds read and the resulting disclosure/panic are confined to the kernel\u0027s own security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - Up to ~65 bytes of kernel stack memory adjacent to buf[256] are copied into the configfs page and returned to userspace, plausibly leaking the stack canary, saved registers, and kernel/list pointers that defeat KASLR and stack protector. This is well beyond a \"few bytes\" bounded read.\nI:N - The (cur_len + len) \u003e PAGE_SIZE check correctly bounds the memcpy destination inside the get_zeroed_page() buffer, so no kernel memory is written out of bounds and no write or control-flow primitive is produced.\nA:H - With CONFIG_FORTIFY_SOURCE (default in distro kernels) the runtime source-size check in fortify_memcpy_chk() fires and calls fortify_panic(), producing a kernel BUG/panic; KASAN builds BUG as well, and the attacker can trigger this at will by re-reading the file."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:07:00.453Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/e6eeee5dc0d9221ff96d1b229b1d0222c8871b84"
},
{
"url": "https://git.kernel.org/stable/c/764a91e2fc9639e07aac93bc70e387e6b1e33084"
},
{
"url": "https://git.kernel.org/stable/c/ddc79fba132b807ff775467acceaf48b456e008b"
},
{
"url": "https://git.kernel.org/stable/c/e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4"
},
{
"url": "https://git.kernel.org/stable/c/f03aa5e39da7d045615b3951d2a6ca1d7132f881"
},
{
"url": "https://git.kernel.org/stable/c/53c6351597e6a17ec6619f6f060d54128cb9a187"
},
{
"url": "https://git.kernel.org/stable/c/4b292286949588bd2818e66ff102db278de8dd26"
},
{
"url": "https://git.kernel.org/stable/c/a150275831b765b0f1de8b8ff52ec5c6933ac15d"
},
{
"url": "https://git.kernel.org/stable/c/27e06650a5eafe832a90fd2604f0c5e920857fae"
}
],
"title": "scsi: target: target_core_configfs: Add length check to avoid buffer overflow",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39998",
"datePublished": "2025-10-15T07:58:22.354Z",
"dateReserved": "2025-04-16T07:20:57.151Z",
"dateUpdated": "2026-08-05T12:07:00.453Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-39998",
"date": "2026-09-20",
"epss": "0.00173",
"percentile": "0.07084"
},
"microsoft_vex": {
"current_release_date": "2025-10-16T01:02:33.000Z",
"cve": "CVE-2025-39998",
"id": "msrc_CVE-2025-39998",
"initial_release_date": "2025-10-02T00:00:00.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "2",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "scsi: target: target_core_configfs: Add length check to avoid buffer overflow",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-39998.json",
"version": "1"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/target/target_core_configfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "e6eeee5dc0d9221ff96d1b229b1d0222c8871b84",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "764a91e2fc9639e07aac93bc70e387e6b1e33084",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "ddc79fba132b807ff775467acceaf48b456e008b",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "f03aa5e39da7d045615b3951d2a6ca1d7132f881",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "53c6351597e6a17ec6619f6f060d54128cb9a187",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "4b292286949588bd2818e66ff102db278de8dd26",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "a150275831b765b0f1de8b8ff52ec5c6933ac15d",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "27e06650a5eafe832a90fd2604f0c5e920857fae",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/target/target_core_configfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.38"
},
{
"lessThan": "2.6.38",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.301",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.246",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.195",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.156",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.110",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.51",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: target_core_configfs: Add length check to avoid buffer overflow\n\nA buffer overflow arises from the usage of snprintf to write into the\nbuffer \"buf\" in target_lu_gp_members_show function located in\n/drivers/target/target_core_configfs.c. This buffer is allocated with\nsize LU_GROUP_NAME_BUF (256 bytes).\n\nsnprintf(...) formats multiple strings into buf with the HBA name\n(hba-\u003ehba_group.cg_item), a slash character, a devicename (dev-\u003e\ndev_group.cg_item) and a newline character, the total formatted string\nlength may exceed the buffer size of 256 bytes.\n\nSince snprintf() returns the total number of bytes that would have been\nwritten (the length of %s/%sn ), this value may exceed the buffer length\n(256 bytes) passed to memcpy(), this will ultimately cause function\nmemcpy reporting a buffer overflow error.\n\nAn additional check of the return value of snprintf() can avoid this\nbuffer overflow."
}
],
"id": "CVE-2025-39998",
"lastModified": "2026-07-30T06:24:05.717",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2025-10-15T08:15:38.077",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/27e06650a5eafe832a90fd2604f0c5e920857fae"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4b292286949588bd2818e66ff102db278de8dd26"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/53c6351597e6a17ec6619f6f060d54128cb9a187"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/764a91e2fc9639e07aac93bc70e387e6b1e33084"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a150275831b765b0f1de8b8ff52ec5c6933ac15d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ddc79fba132b807ff775467acceaf48b456e008b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e6eeee5dc0d9221ff96d1b229b1d0222c8871b84"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f03aa5e39da7d045615b3951d2a6ca1d7132f881"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-07-30T08:53:23+00:00",
"cve": "CVE-2025-39998",
"id": "CVE-2025-39998",
"initial_release_date": "2025-10-15T00:00:00+00:00",
"product_status:known_affected": "274",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Linux kernel: Buffer overflow in target_lu_gp_members_show can lead to arbitrary code execution",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-39998.json",
"version": "3"
}
}
}
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-39998
Vulnerability from fkie_nvd - Published: 2025-10-15 08:15 - Updated: 2026-07-30 06:24| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/target/target_core_configfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "e6eeee5dc0d9221ff96d1b229b1d0222c8871b84",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "764a91e2fc9639e07aac93bc70e387e6b1e33084",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "ddc79fba132b807ff775467acceaf48b456e008b",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "f03aa5e39da7d045615b3951d2a6ca1d7132f881",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "53c6351597e6a17ec6619f6f060d54128cb9a187",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "4b292286949588bd2818e66ff102db278de8dd26",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "a150275831b765b0f1de8b8ff52ec5c6933ac15d",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
},
{
"lessThan": "27e06650a5eafe832a90fd2604f0c5e920857fae",
"status": "affected",
"version": "c66ac9db8d4ad9994a02b3e933ea2ccc643e1fe5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/target/target_core_configfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.38"
},
{
"lessThan": "2.6.38",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.301",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.246",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.195",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.156",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.110",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.51",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: target_core_configfs: Add length check to avoid buffer overflow\n\nA buffer overflow arises from the usage of snprintf to write into the\nbuffer \"buf\" in target_lu_gp_members_show function located in\n/drivers/target/target_core_configfs.c. This buffer is allocated with\nsize LU_GROUP_NAME_BUF (256 bytes).\n\nsnprintf(...) formats multiple strings into buf with the HBA name\n(hba-\u003ehba_group.cg_item), a slash character, a devicename (dev-\u003e\ndev_group.cg_item) and a newline character, the total formatted string\nlength may exceed the buffer size of 256 bytes.\n\nSince snprintf() returns the total number of bytes that would have been\nwritten (the length of %s/%sn ), this value may exceed the buffer length\n(256 bytes) passed to memcpy(), this will ultimately cause function\nmemcpy reporting a buffer overflow error.\n\nAn additional check of the return value of snprintf() can avoid this\nbuffer overflow."
}
],
"id": "CVE-2025-39998",
"lastModified": "2026-07-30T06:24:05.717",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2025-10-15T08:15:38.077",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/27e06650a5eafe832a90fd2604f0c5e920857fae"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4b292286949588bd2818e66ff102db278de8dd26"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/53c6351597e6a17ec6619f6f060d54128cb9a187"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/764a91e2fc9639e07aac93bc70e387e6b1e33084"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a150275831b765b0f1de8b8ff52ec5c6933ac15d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ddc79fba132b807ff775467acceaf48b456e008b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e6eeee5dc0d9221ff96d1b229b1d0222c8871b84"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f03aa5e39da7d045615b3951d2a6ca1d7132f881"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
GHSA-H5VM-JVGF-QF7M
Vulnerability from github – Published: 2025-10-15 09:30 – Updated: 2026-07-30 06:32In the Linux kernel, the following vulnerability has been resolved:
scsi: target: target_core_configfs: Add length check to avoid buffer overflow
A buffer overflow arises from the usage of snprintf to write into the buffer "buf" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes).
snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes.
Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error.
An additional check of the return value of snprintf() can avoid this buffer overflow.
{
"affected": [],
"aliases": [
"CVE-2025-39998"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T08:15:38Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: target_core_configfs: Add length check to avoid buffer overflow\n\nA buffer overflow arises from the usage of snprintf to write into the\nbuffer \"buf\" in target_lu_gp_members_show function located in\n/drivers/target/target_core_configfs.c. This buffer is allocated with\nsize LU_GROUP_NAME_BUF (256 bytes).\n\nsnprintf(...) formats multiple strings into buf with the HBA name\n(hba-\u003ehba_group.cg_item), a slash character, a devicename (dev-\u003e\ndev_group.cg_item) and a newline character, the total formatted string\nlength may exceed the buffer size of 256 bytes.\n\nSince snprintf() returns the total number of bytes that would have been\nwritten (the length of %s/%sn ), this value may exceed the buffer length\n(256 bytes) passed to memcpy(), this will ultimately cause function\nmemcpy reporting a buffer overflow error.\n\nAn additional check of the return value of snprintf() can avoid this\nbuffer overflow.",
"id": "GHSA-h5vm-jvgf-qf7m",
"modified": "2026-07-30T06:32:12Z",
"published": "2025-10-15T09:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27e06650a5eafe832a90fd2604f0c5e920857fae"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b292286949588bd2818e66ff102db278de8dd26"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53c6351597e6a17ec6619f6f060d54128cb9a187"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/764a91e2fc9639e07aac93bc70e387e6b1e33084"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a150275831b765b0f1de8b8ff52ec5c6933ac15d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ddc79fba132b807ff775467acceaf48b456e008b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e6eeee5dc0d9221ff96d1b229b1d0222c8871b84"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e73fe0eefac3e15bf88fb5b4afae4c76215ee4d4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f03aa5e39da7d045615b3951d2a6ca1d7132f881"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2025-39998
Vulnerability from csaf_microsoft - Published: 2025-10-02 00:00 - Updated: 2025-10-16 01:02OESA-2025-2533 (CVE-2022-50299)
Vulnerability from osv_openeuler – Published: 2025-10-24 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:
md: Replace snprintf with scnprintf
Current code produces a warning as shown below when total characters in the constituent block device names plus the slashes exceeds 200. snprintf() returns the number of characters generated from the given input, which could cause the expression “200 – len” to wrap around to a large positive number. Fix this by using scnprintf() instead, which returns the actual number of characters written into the buffer.
[ 1513.267938] ------------[ cut here ]------------ [ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510 [ 1513.267944] Modules linked in: <snip> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510 <-snip-> [ 1513.267982] Call Trace: [ 1513.267986] snprintf+0x45/0x70 [ 1513.267990] ? disk_name+0x71/0xa0 [ 1513.267993] dump_zones+0x114/0x240 [raid0] [ 1513.267996] ? _cond_resched+0x19/0x40 [ 1513.267998] raid0_run+0x19e/0x270 [raid0] [ 1513.268000] md_run+0x5e0/0xc50 [ 1513.268003] ? security_capable+0x3f/0x60 [ 1513.268005] do_md_run+0x19/0x110 [ 1513.268006] md_ioctl+0x195e/0x1f90 [ 1513.268007] blkdev_ioctl+0x91f/0x9f0 [ 1513.268010] block_ioctl+0x3d/0x50 [ 1513.268012] do_vfs_ioctl+0xa9/0x640 [ 1513.268014] ? __fput+0x162/0x260 [ 1513.268016] ksys_ioctl+0x75/0x80 [ 1513.268017] __x64_sys_ioctl+0x1a/0x20 [ 1513.268019] do_syscall_64+0x5e/0x200 [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9(CVE-2022-50299)
In the Linux kernel, the following vulnerability has been resolved:
nbd: Fix hung when signal interrupts nbd_start_device_ioctl()
syzbot reported hung task [1]. The following program is a simplified version of the reproducer:
int main(void) { int sv[2], fd;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)
return 1;
if ((fd = open("/dev/nbd0", 0)) < 0)
return 1;
if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)
return 1;
if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)
return 1;
if (ioctl(fd, NBD_DO_IT) < 0)
return 1;
return 0;
}
When signal interrupt nbd_start_device_ioctl() waiting the condition atomic_read(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs.
This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbd_start_device_ioctl().(CVE-2022-50314)
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix oops during encryption
When running xfstests against Azure the following oops occurred on an arm64 system
Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0
This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary.
To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov...
Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses.(CVE-2022-50341)
In the Linux kernel, the following vulnerability has been resolved:
drivers/md/md-bitmap: check the return value of md_bitmap_get_counter()
Check the return value of md_bitmap_get_counter() in case it returns NULL pointer, which will result in a null pointer dereference.
v2: update the check to include other dereference(CVE-2022-50402)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: ac97: fix possible memory leak in snd_ac97_dev_register()
If device_register() fails in snd_ac97_dev_register(), it should call put_device() to give up reference, or the name allocated in dev_set_name() is leaked.(CVE-2022-50427)
In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING
vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here. Ensure that we mark current as TASK_RUNNING for sleepable context.
[ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0 [ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160 [ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1 [ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 77.554912] RIP: 0010:__might_sleep+0x116/0x160 [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282 [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000 [ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9 [ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba [ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60 [ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660 [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000 [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0 [ 77.554942] Call Trace: [ 77.554944] <TASK> [ 77.554952] mutex_lock+0x78/0xf0 [ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300] [ 77.554981] sdio_irq_thread+0x25c/0x5b0 [ 77.555006] kthread+0x2b8/0x370 [ 77.555017] ret_from_fork+0x1f/0x30 [ 77.555023] </TASK> [ 77.555025] ---[ end trace 0000000000000000 ]---(CVE-2022-50430)
In the Linux kernel, the following vulnerability has been resolved:
clk: samsung: Fix memory leak in _samsung_clk_register_pll()
If clk_register() fails, @pll->rate_table may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.(CVE-2022-50449)
In the Linux kernel, the following vulnerability has been resolved:
binfmt_misc: fix shift-out-of-bounds in check_special_flags
UBSAN reported a shift-out-of-bounds warning:
left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1
Since the type of Node's flags is unsigned long, we should define these macros with same type too.(CVE-2022-50497)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: prevent soft lockup while flush writes
Currently, there is no limit for raid1/raid10 plugged bio. While flushing writes, raid1 has cond_resched() while raid10 doesn't, and too many writes can cause soft lockup.
Follow up soft lockup can be triggered easily with writeback test for raid10 with ramdisks:
watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293] Call Trace: <TASK> call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xed/0x1a0 kmem_cache_free+0xfd/0x300 mempool_free_slab+0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0
Fix the problem by adding cond_resched() to raid10 like what raid1 did.
Note that unlimited plugged bio still need to be optimized, for example, in the case of lots of dirty pages writeback, this will take lots of memory and io will spend a long time in plug, hence io latency is bad.(CVE-2023-53151)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix leak of 'r10bio->remaining' for recovery
raid10_sync_request() will add 'r10bio->remaining' for both rdev and replacement rdev. However, if the read io fails, recovery_request_write() returns without issuing the write io, in this case, end_sync_request() is only called once and 'remaining' is leaked, cause an io hang.
Fix the problem by decreasing 'remaining' according to if 'bio' and 'repl_bio' is valid.(CVE-2023-53299)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix wrong setting of max_corr_read_errors
There is no input check when echo md/max_read_errors and overflow might occur. Add check of input number.(CVE-2023-53313)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Wait for io return on terminate rport
System crash due to use after free. Current code allows terminate_rport_io to exit before making sure all IOs has returned. For FCP-2 device, IO's can hang on in HW because driver has not tear down the session in FW at first sign of cable pull. When dev_loss_tmo timer pops, terminate_rport_io is called and upper layer is about to free various resources. Terminate_rport_io trigger qla to do the final cleanup, but the cleanup might not be fast enough where it leave qla still holding on to the same resource.
Wait for IO's to return to upper layer before resources are freed.(CVE-2023-53322)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: check slab-out-of-bounds in md_bitmap_get_counter
If we write a large number to md/bitmap_set_bits, md_bitmap_checkpage() will return -EINVAL because 'page >= bitmap->pages', but the return value was not checked immediately in md_bitmap_get_counter() in order to set *blocks value and slab-out-of-bounds occurs.
Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() and return directly if true.(CVE-2023-53357)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request
There are two check of 'mreplace' in raid10_sync_request(). In the first check, 'need_replace' will be set and 'mreplace' will be used later if no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be set to NULL if it is Faulty, but 'need_replace' will not be changed accordingly. null-ptr-deref occurs if Faulty is set between two check.
Fix it by merging two checks into one. And replace 'need_replace' with 'mreplace' because their values are always the same.(CVE-2023-53380)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Handle enclosure with just a primary component gracefully
This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") and introduces proper handling of case where there are no detected secondary components, but primary component (enumerated in num_enclosures) does exist. That fix was originally proposed by Ding Hui <(CVE-2023-53431)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla4xxx: Add length check when parsing nlattrs
There are three places that qla4xxx parses nlattrs:
-
qla4xxx_set_chap_entry()
-
qla4xxx_iface_set_param()
-
qla4xxx_sysfs_ddb_set_param()
and each of them directly converts the nlattr to specific pointer of structure without length checking. This could be dangerous as those attributes are not validated and a malformed nlattr (e.g., length 0) could result in an OOB read that leaks heap dirty data.
Add the nla_len check before accessing the nlattr data and return EINVAL if the length check fails.(CVE-2023-53456)
In the Linux kernel, the following vulnerability has been resolved:
udf: Do not bother merging very long extents
When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together.(CVE-2023-53506)
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Add histograms to hist_vars if they have referenced variables
Hist triggers can have referenced variables without having direct variables fields. This can be the case if referenced variables are added for trigger actions. In this case the newly added references will not have field variables. Not taking such referenced variables into consideration can result in a bug where it would be possible to remove hist trigger with variables being refenced. This will result in a bug that is easily reproducable like so
$ cd /sys/kernel/tracing $ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events $ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger $ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger $ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger
[ 100.263533] ================================================================== [ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180 [ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439 [ 100.266320] [ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4 [ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 [ 100.268561] Call Trace: [ 100.268902] <TASK> [ 100.269189] dump_stack_lvl+0x4c/0x70 [ 100.269680] print_report+0xc5/0x600 [ 100.270165] ? resolve_var_refs+0xc7/0x180 [ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0 [ 100.271389] ? resolve_var_refs+0xc7/0x180 [ 100.271913] kasan_report+0xbd/0x100 [ 100.272380] ? resolve_var_refs+0xc7/0x180 [ 100.272920] __asan_load8+0x71/0xa0 [ 100.273377] resolve_var_refs+0xc7/0x180 [ 100.273888] event_hist_trigger+0x749/0x860 [ 100.274505] ? kasan_save_stack+0x2a/0x50 [ 100.275024] ? kasan_set_track+0x29/0x40 [ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10 [ 100.276138] ? ksys_write+0xd1/0x170 [ 100.276607] ? do_syscall_64+0x3c/0x90 [ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 100.277771] ? destroy_hist_data+0x446/0x470 [ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860 [ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10 [ 100.279627] ? __kasan_check_write+0x18/0x20 [ 100.280177] ? mutex_unlock+0x85/0xd0 [ 100.280660] ? __pfx_mutex_unlock+0x10/0x10 [ 100.281200] ? kfree+0x7b/0x120 [ 100.281619] ? _kasanslab_free+0x15d/0x1d0 [ 100.282197] ? event_trigger_write+0xac/0x100 [ 100.282764] ? kasan_slab_free+0x16/0x20 [ 100.283293] ? __kmem_cache_free+0x153/0x2f0 [ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250 [ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10 [ 100.285221] ? event_trigger_write+0xbc/0x100 [ 100.285781] ? __kasan_check_read+0x15/0x20 [ 100.286321] ? __bitmap_weight+0x66/0xa0 [ 100.286833] ? _find_next_bit+0x46/0xe0 [ 100.287334] ? task_mm_cid_work+0x37f/0x450 [ 100.287872] event_triggers_call+0x84/0x150 [ 100.288408] trace_event_buffer_commit+0x339/0x430 [ 100.289073] ? ring_buffer_event_data+0x3f/0x60 [ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0 [ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0 [ 100.298653] syscall_enter_from_user_mode+0x32/0x40 [ 100.301808] do_syscall_64+0x1a/0x90 [ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 100.307775] RIP: 0033:0x7f686c75c1cb [ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48 [ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021 [ 100.321200] RA ---truncated---(CVE-2023-53560)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btrtl: Prevent potential NULL dereference
The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch:
drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'(CVE-2025-37792)
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.
v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag(CVE-2025-38449)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a race when updating an existing write
After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head.
So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().(CVE-2025-39697)
A heap-based buffer overflow vulnerability was found in the e1000_set_eeprom function of the Linux kernel. The vulnerability is caused by lack of input validation for the requested length of EEPROM changes, which may lead to heap overflow. Attackers can exploit this vulnerability to compromise confidentiality, integrity, and availability of memory.(CVE-2025-39898)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2510.3.0.0348.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2510.3.0.0348.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: Replace snprintf with scnprintf\n\nCurrent code produces a warning as shown below when total characters\nin the constituent block device names plus the slashes exceeds 200.\nsnprintf() returns the number of characters generated from the given\ninput, which could cause the expression \u201c200 \u2013 len\u201d to wrap around\nto a large positive number. Fix this by using scnprintf() instead,\nwhich returns the actual number of characters written into the buffer.\n\n[ 1513.267938] ------------[ cut here ]------------\n[ 1513.267943] WARNING: CPU: 15 PID: 37247 at \u0026lt;snip\u0026gt;/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510\n[ 1513.267944] Modules linked in: \u0026lt;snip\u0026gt;\n[ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu\n[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510\n\u0026lt;-snip-\u0026gt;\n[ 1513.267982] Call Trace:\n[ 1513.267986] snprintf+0x45/0x70\n[ 1513.267990] ? disk_name+0x71/0xa0\n[ 1513.267993] dump_zones+0x114/0x240 [raid0]\n[ 1513.267996] ? _cond_resched+0x19/0x40\n[ 1513.267998] raid0_run+0x19e/0x270 [raid0]\n[ 1513.268000] md_run+0x5e0/0xc50\n[ 1513.268003] ? security_capable+0x3f/0x60\n[ 1513.268005] do_md_run+0x19/0x110\n[ 1513.268006] md_ioctl+0x195e/0x1f90\n[ 1513.268007] blkdev_ioctl+0x91f/0x9f0\n[ 1513.268010] block_ioctl+0x3d/0x50\n[ 1513.268012] do_vfs_ioctl+0xa9/0x640\n[ 1513.268014] ? __fput+0x162/0x260\n[ 1513.268016] ksys_ioctl+0x75/0x80\n[ 1513.268017] __x64_sys_ioctl+0x1a/0x20\n[ 1513.268019] do_syscall_64+0x5e/0x200\n[ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9(CVE-2022-50299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: Fix hung when signal interrupts nbd_start_device_ioctl()\n\nsyzbot reported hung task [1]. The following program is a simplified\nversion of the reproducer:\n\nint main(void)\n{\n\tint sv[2], fd;\n\n\tif (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) \u0026lt; 0)\n\t\treturn 1;\n\tif ((fd = open(\u0026quot;/dev/nbd0\u0026quot;, 0)) \u0026lt; 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) \u0026lt; 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_SET_SOCK, sv[0]) \u0026lt; 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_DO_IT) \u0026lt; 0)\n\t\treturn 1;\n\treturn 0;\n}\n\nWhen signal interrupt nbd_start_device_ioctl() waiting the condition\natomic_read(\u0026amp;config-\u0026gt;recv_threads) == 0, the task can hung because it\nwaits the completion of the inflight IOs.\n\nThis patch fixes the issue by clearing queue, not just shutdown, when\nsignal interrupt nbd_start_device_ioctl().(CVE-2022-50314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix oops during encryption\n\nWhen running xfstests against Azure the following oops occurred on an\narm64 system\n\n Unable to handle kernel write to read-only memory at virtual address\n ffff0001221cf000\n Mem abort info:\n ESR = 0x9600004f\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x0f: level 3 permission fault\n Data abort info:\n ISV = 0, ISS = 0x0000004f\n CM = 0, WnR = 1\n swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000\n [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,\n pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787\n Internal error: Oops: 9600004f [#1] PREEMPT SMP\n ...\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)\n pc : __memcpy+0x40/0x230\n lr : scatterwalk_copychunks+0xe0/0x200\n sp : ffff800014e92de0\n x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008\n x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008\n x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000\n x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014\n x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058\n x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590\n x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580\n x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005\n x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001\n x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000\n Call trace:\n __memcpy+0x40/0x230\n scatterwalk_map_and_copy+0x98/0x100\n crypto_ccm_encrypt+0x150/0x180\n crypto_aead_encrypt+0x2c/0x40\n crypt_message+0x750/0x880\n smb3_init_transform_rq+0x298/0x340\n smb_send_rqst.part.11+0xd8/0x180\n smb_send_rqst+0x3c/0x100\n compound_send_recv+0x534/0xbc0\n smb2_query_info_compound+0x32c/0x440\n smb2_set_ea+0x438/0x4c0\n cifs_xattr_set+0x5d4/0x7c0\n\nThis is because in scatterwalk_copychunks(), we attempted to write to\na buffer (@sign) that was allocated in the stack (vmalloc area) by\ncrypt_message() and thus accessing its remaining 8 (x2) bytes ended up\ncrossing a page boundary.\n\nTo simply fix it, we could just pass @sign kmalloc\u0026apos;d from\ncrypt_message() and then we\u0026apos;re done. Luckily, we don\u0026apos;t seem to pass\nany other vmalloc\u0026apos;d buffers in smb_rqst::rq_iov...\n\nInstead, let\u0026apos;s map the correct pages and offsets from vmalloc buffers\nas well in cifs_sg_set_buf() and then avoiding such oopses.(CVE-2022-50341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/md/md-bitmap: check the return value of md_bitmap_get_counter()\n\nCheck the return value of md_bitmap_get_counter() in case it returns\nNULL pointer, which will result in a null pointer dereference.\n\nv2: update the check to include other dereference(CVE-2022-50402)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ac97: fix possible memory leak in snd_ac97_dev_register()\n\nIf device_register() fails in snd_ac97_dev_register(), it should\ncall put_device() to give up reference, or the name allocated in\ndev_set_name() is leaked.(CVE-2022-50427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING\n\nvub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.\nEnsure that we mark current as TASK_RUNNING for sleepable context.\n\n[ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [\u0026lt;ffffffff92a72c1d\u0026gt;] sdio_irq_thread+0x17d/0x5b0\n[ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160\n[ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1\n[ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020\n[ 77.554912] RIP: 0010:__might_sleep+0x116/0x160\n[ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282\n[ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000\n[ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9\n[ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba\n[ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60\n[ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660\n[ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000\n[ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0\n[ 77.554942] Call Trace:\n[ 77.554944] \u0026lt;TASK\u0026gt;\n[ 77.554952] mutex_lock+0x78/0xf0\n[ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300]\n[ 77.554981] sdio_irq_thread+0x25c/0x5b0\n[ 77.555006] kthread+0x2b8/0x370\n[ 77.555017] ret_from_fork+0x1f/0x30\n[ 77.555023] \u0026lt;/TASK\u0026gt;\n[ 77.555025] ---[ end trace 0000000000000000 ]---(CVE-2022-50430)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: samsung: Fix memory leak in _samsung_clk_register_pll()\n\nIf clk_register() fails, @pll-\u0026gt;rate_table may have allocated memory by\nkmemdup(), so it needs to be freed, otherwise will cause memory leak\nissue, this patch fixes it.(CVE-2022-50449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: fix shift-out-of-bounds in check_special_flags\n\nUBSAN reported a shift-out-of-bounds warning:\n\n left shift of 1 by 31 places cannot be represented in type \u0026apos;int\u0026apos;\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106\n ubsan_epilogue+0xa/0x44 lib/ubsan.c:151\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322\n check_special_flags fs/binfmt_misc.c:241 [inline]\n create_entry fs/binfmt_misc.c:456 [inline]\n bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654\n vfs_write+0x11e/0x580 fs/read_write.c:582\n ksys_write+0xcf/0x120 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x4194e1\n\nSince the type of Node\u0026apos;s flags is unsigned long, we should define these\nmacros with same type too.(CVE-2022-50497)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: prevent soft lockup while flush writes\n\nCurrently, there is no limit for raid1/raid10 plugged bio. While flushing\nwrites, raid1 has cond_resched() while raid10 doesn\u0026apos;t, and too many\nwrites can cause soft lockup.\n\nFollow up soft lockup can be triggered easily with writeback test for\nraid10 with ramdisks:\n\nwatchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n call_rcu+0x16/0x20\n put_object+0x41/0x80\n __delete_object+0x50/0x90\n delete_object_full+0x2b/0x40\n kmemleak_free+0x46/0xa0\n slab_free_freelist_hook.constprop.0+0xed/0x1a0\n kmem_cache_free+0xfd/0x300\n mempool_free_slab+0x1f/0x30\n mempool_free+0x3a/0x100\n bio_free+0x59/0x80\n bio_put+0xcf/0x2c0\n free_r10bio+0xbf/0xf0\n raid_end_bio_io+0x78/0xb0\n one_write_done+0x8a/0xa0\n raid10_end_write_request+0x1b4/0x430\n bio_endio+0x175/0x320\n brd_submit_bio+0x3b9/0x9b7 [brd]\n __submit_bio+0x69/0xe0\n submit_bio_noacct_nocheck+0x1e6/0x5a0\n submit_bio_noacct+0x38c/0x7e0\n flush_pending_writes+0xf0/0x240\n raid10d+0xac/0x1ed0\n\nFix the problem by adding cond_resched() to raid10 like what raid1 did.\n\nNote that unlimited plugged bio still need to be optimized, for example,\nin the case of lots of dirty pages writeback, this will take lots of\nmemory and io will spend a long time in plug, hence io latency is bad.(CVE-2023-53151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix leak of \u0026apos;r10bio-\u0026gt;remaining\u0026apos; for recovery\n\nraid10_sync_request() will add \u0026apos;r10bio-\u0026gt;remaining\u0026apos; for both rdev and\nreplacement rdev. However, if the read io fails, recovery_request_write()\nreturns without issuing the write io, in this case, end_sync_request()\nis only called once and \u0026apos;remaining\u0026apos; is leaked, cause an io hang.\n\nFix the problem by decreasing \u0026apos;remaining\u0026apos; according to if \u0026apos;bio\u0026apos; and\n\u0026apos;repl_bio\u0026apos; is valid.(CVE-2023-53299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix wrong setting of max_corr_read_errors\n\nThere is no input check when echo md/max_read_errors and overflow might\noccur. Add check of input number.(CVE-2023-53313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Wait for io return on terminate rport\n\nSystem crash due to use after free.\nCurrent code allows terminate_rport_io to exit before making\nsure all IOs has returned. For FCP-2 device, IO\u0026apos;s can hang\non in HW because driver has not tear down the session in FW at\nfirst sign of cable pull. When dev_loss_tmo timer pops,\nterminate_rport_io is called and upper layer is about to\nfree various resources. Terminate_rport_io trigger qla to do\nthe final cleanup, but the cleanup might not be fast enough where it\nleave qla still holding on to the same resource.\n\nWait for IO\u0026apos;s to return to upper layer before resources are freed.(CVE-2023-53322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: check slab-out-of-bounds in md_bitmap_get_counter\n\nIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()\nwill return -EINVAL because \u0026apos;page \u0026gt;= bitmap-\u0026gt;pages\u0026apos;, but the return value\nwas not checked immediately in md_bitmap_get_counter() in order to set\n*blocks value and slab-out-of-bounds occurs.\n\nMove check of \u0026apos;page \u0026gt;= bitmap-\u0026gt;pages\u0026apos; to md_bitmap_get_counter() and\nreturn directly if true.(CVE-2023-53357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix null-ptr-deref of mreplace in raid10_sync_request\n\nThere are two check of \u0026apos;mreplace\u0026apos; in raid10_sync_request(). In the first\ncheck, \u0026apos;need_replace\u0026apos; will be set and \u0026apos;mreplace\u0026apos; will be used later if\nno-Faulty \u0026apos;mreplace\u0026apos; exists, In the second check, \u0026apos;mreplace\u0026apos; will be\nset to NULL if it is Faulty, but \u0026apos;need_replace\u0026apos; will not be changed\naccordingly. null-ptr-deref occurs if Faulty is set between two check.\n\nFix it by merging two checks into one. And replace \u0026apos;need_replace\u0026apos; with\n\u0026apos;mreplace\u0026apos; because their values are always the same.(CVE-2023-53380)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Handle enclosure with just a primary component gracefully\n\nThis reverts commit 3fe97ff3d949 (\u0026quot;scsi: ses: Don\u0026apos;t attach if enclosure\nhas no components\u0026quot;) and introduces proper handling of case where there are\nno detected secondary components, but primary component (enumerated in\nnum_enclosures) does exist. That fix was originally proposed by Ding Hui\n\u0026lt;(CVE-2023-53431)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Add length check when parsing nlattrs\n\nThere are three places that qla4xxx parses nlattrs:\n\n - qla4xxx_set_chap_entry()\n\n - qla4xxx_iface_set_param()\n\n - qla4xxx_sysfs_ddb_set_param()\n\nand each of them directly converts the nlattr to specific pointer of\nstructure without length checking. This could be dangerous as those\nattributes are not validated and a malformed nlattr (e.g., length 0) could\nresult in an OOB read that leaks heap dirty data.\n\nAdd the nla_len check before accessing the nlattr data and return EINVAL if\nthe length check fails.(CVE-2023-53456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: Do not bother merging very long extents\n\nWhen merging very long extents we try to push as much length as possible\nto the first extent. However this is unnecessarily complicated and not\nreally worth the trouble. Furthermore there was a bug in the logic\nresulting in corrupting extents in the file as syzbot reproducer shows.\nSo just don\u0026apos;t bother with the merging of extents that are too long\ntogether.(CVE-2023-53506)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Add histograms to hist_vars if they have referenced variables\n\nHist triggers can have referenced variables without having direct\nvariables fields. This can be the case if referenced variables are added\nfor trigger actions. In this case the newly added references will not\nhave field variables. Not taking such referenced variables into\nconsideration can result in a bug where it would be possible to remove\nhist trigger with variables being refenced. This will result in a bug\nthat is easily reproducable like so\n\n$ cd /sys/kernel/tracing\n$ echo \u0026apos;synthetic_sys_enter char[] comm; long id\u0026apos; \u0026gt;\u0026gt; synthetic_events\n$ echo \u0026apos;hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname\u0026apos; \u0026gt;\u0026gt; events/raw_syscalls/sys_enter/trigger\n$ echo \u0026apos;hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)\u0026apos; \u0026gt;\u0026gt; events/raw_syscalls/sys_enter/trigger\n$ echo \u0026apos;!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname\u0026apos; \u0026gt;\u0026gt; events/raw_syscalls/sys_enter/trigger\n\n[ 100.263533] ==================================================================\n[ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180\n[ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439\n[ 100.266320]\n[ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4\n[ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\n[ 100.268561] Call Trace:\n[ 100.268902] \u0026lt;TASK\u0026gt;\n[ 100.269189] dump_stack_lvl+0x4c/0x70\n[ 100.269680] print_report+0xc5/0x600\n[ 100.270165] ? resolve_var_refs+0xc7/0x180\n[ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0\n[ 100.271389] ? resolve_var_refs+0xc7/0x180\n[ 100.271913] kasan_report+0xbd/0x100\n[ 100.272380] ? resolve_var_refs+0xc7/0x180\n[ 100.272920] __asan_load8+0x71/0xa0\n[ 100.273377] resolve_var_refs+0xc7/0x180\n[ 100.273888] event_hist_trigger+0x749/0x860\n[ 100.274505] ? kasan_save_stack+0x2a/0x50\n[ 100.275024] ? kasan_set_track+0x29/0x40\n[ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10\n[ 100.276138] ? ksys_write+0xd1/0x170\n[ 100.276607] ? do_syscall_64+0x3c/0x90\n[ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 100.277771] ? destroy_hist_data+0x446/0x470\n[ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860\n[ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10\n[ 100.279627] ? __kasan_check_write+0x18/0x20\n[ 100.280177] ? mutex_unlock+0x85/0xd0\n[ 100.280660] ? __pfx_mutex_unlock+0x10/0x10\n[ 100.281200] ? kfree+0x7b/0x120\n[ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0\n[ 100.282197] ? event_trigger_write+0xac/0x100\n[ 100.282764] ? __kasan_slab_free+0x16/0x20\n[ 100.283293] ? __kmem_cache_free+0x153/0x2f0\n[ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250\n[ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10\n[ 100.285221] ? event_trigger_write+0xbc/0x100\n[ 100.285781] ? __kasan_check_read+0x15/0x20\n[ 100.286321] ? __bitmap_weight+0x66/0xa0\n[ 100.286833] ? _find_next_bit+0x46/0xe0\n[ 100.287334] ? task_mm_cid_work+0x37f/0x450\n[ 100.287872] event_triggers_call+0x84/0x150\n[ 100.288408] trace_event_buffer_commit+0x339/0x430\n[ 100.289073] ? ring_buffer_event_data+0x3f/0x60\n[ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0\n[ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0\n[ 100.298653] syscall_enter_from_user_mode+0x32/0x40\n[ 100.301808] do_syscall_64+0x1a/0x90\n[ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[ 100.307775] RIP: 0033:0x7f686c75c1cb\n[ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48\n[ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021\n[ 100.321200] RA\n---truncated---(CVE-2023-53560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: Prevent potential NULL dereference\n\nThe btrtl_initialize() function checks that rtl_load_file() either\nhad an error or it loaded a zero length file. However, if it loaded\na zero length file then the error code is not set correctly. It\nresults in an error pointer vs NULL bug, followed by a NULL pointer\ndereference. This was detected by Smatch:\n\ndrivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to \u0026apos;ERR_PTR\u0026apos;(CVE-2025-37792)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gem: Acquire references on GEM handles for framebuffers\n\nA GEM handle can be released while the GEM buffer object is attached\nto a DRM framebuffer. This leads to the release of the dma-buf backing\nthe buffer object, if any. [1] Trying to use the framebuffer in further\nmode-setting operations leads to a segmentation fault. Most easily\nhappens with driver that use shadow planes for vmap-ing the dma-buf\nduring a page flip. An example is shown below.\n\n[ 156.791968] ------------[ cut here ]------------\n[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430\n[...]\n[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430\n[ 157.043420] Call Trace:\n[ 157.045898] \u0026lt;TASK\u0026gt;\n[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710\n[ 157.065567] ? dma_buf_vmap+0x224/0x430\n[ 157.069446] ? __warn.cold+0x58/0xe4\n[ 157.073061] ? dma_buf_vmap+0x224/0x430\n[ 157.077111] ? report_bug+0x1dd/0x390\n[ 157.080842] ? handle_bug+0x5e/0xa0\n[ 157.084389] ? exc_invalid_op+0x14/0x50\n[ 157.088291] ? asm_exc_invalid_op+0x16/0x20\n[ 157.092548] ? dma_buf_vmap+0x224/0x430\n[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230\n[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10\n[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10\n[ 157.110697] drm_gem_shmem_vmap+0x74/0x710\n[ 157.114866] drm_gem_vmap+0xa9/0x1b0\n[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0\n[ 157.123086] drm_gem_fb_vmap+0xab/0x300\n[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10\n[ 157.133032] ? lockdep_init_map_type+0x19d/0x880\n[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0\n[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180\n[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40\n[...]\n[ 157.346424] ---[ end trace 0000000000000000 ]---\n\nAcquiring GEM handles for the framebuffer\u0026apos;s GEM buffer objects prevents\nthis from happening. The framebuffer\u0026apos;s cleanup later puts the handle\nreferences.\n\nCommit 1a148af06000 (\u0026quot;drm/gem-shmem: Use dma_buf from GEM object\ninstance\u0026quot;) triggers the segmentation fault easily by using the dma-buf\nfield more widely. The underlying issue with reference counting has\nbeen present before.\n\nv2:\n- acquire the handle instead of the BO (Christian)\n- fix comment style (Christian)\n- drop the Fixes tag (Christian)\n- rename err_ gotos\n- add missing Link tag(CVE-2025-38449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a race when updating an existing write\n\nAfter nfs_lock_and_join_requests() tests for whether the request is\nstill attached to the mapping, nothing prevents a call to\nnfs_inode_remove_request() from succeeding until we actually lock the\npage group.\nThe reason is that whoever called nfs_inode_remove_request() doesn\u0026apos;t\nnecessarily have a lock on the page group head.\n\nSo in order to avoid races, let\u0026apos;s take the page group lock earlier in\nnfs_lock_and_join_requests(), and hold it across the removal of the\nrequest in nfs_inode_remove_request().(CVE-2025-39697)\n\nA heap-based buffer overflow vulnerability was found in the e1000_set_eeprom function of the Linux kernel. The vulnerability is caused by lack of input validation for the requested length of EEPROM changes, which may lead to heap overflow. Attackers can exploit this vulnerability to compromise confidentiality, integrity, and availability of memory.(CVE-2025-39898)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)",
"id": "OESA-2025-2533",
"modified": "2026-08-06T11:09:37Z",
"published": "2025-10-24T11:09:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2533"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50299"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50314"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50341"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50402"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50430"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50497"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53151"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53299"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53357"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53380"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53431"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53456"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53506"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37792"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50299",
"CVE-2022-50314",
"CVE-2022-50341",
"CVE-2022-50402",
"CVE-2022-50427",
"CVE-2022-50430",
"CVE-2022-50449",
"CVE-2022-50497",
"CVE-2023-53151",
"CVE-2023-53299",
"CVE-2023-53313",
"CVE-2023-53322",
"CVE-2023-53357",
"CVE-2023-53380",
"CVE-2023-53431",
"CVE-2023-53456",
"CVE-2023-53506",
"CVE-2023-53560",
"CVE-2025-37792",
"CVE-2025-38449",
"CVE-2025-39697",
"CVE-2025-39898",
"CVE-2025-39998"
]
}
OESA-2025-2551 (CVE-2024-53168)
Vulnerability from osv_openeuler – Published: 2025-10-31 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:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:
x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()
Xen doesn't offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results in the following warning:
unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0) Call Trace: xen_read_msr+0x1e/0x30 amd_get_mmconfig_range+0x2b/0x80 quirk_amd_mmconfig_area+0x28/0x100 pnp_fixup_device+0x39/0x50 __pnp_add_device+0xf/0x150 pnp_add_device+0x3d/0x100 pnpacpi_add_device_handler+0x1f9/0x280 acpi_ns_get_device_callback+0x104/0x1c0 acpi_ns_walk_namespace+0x1d0/0x260 acpi_get_devices+0x8a/0xb0 pnpacpi_init+0x50/0x80 do_one_initcall+0x46/0x2e0 kernel_init_freeable+0x1da/0x2f0 kernel_init+0x16/0x1b0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30
based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.
This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.(CVE-2025-21913)
In the Linux kernel, the following vulnerability has been resolved:
pds_core: Prevent possible adminq overflow/stuck condition
The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion.
On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW.
As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.(CVE-2025-37987)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: fix NULL dereference on unbind due to stale coupling data
Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind.
This can happen during runtime PM or other regulator operations that rely on coupling metadata.
For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state.
Ensure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().
When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: fix panic due to PSLVERR
When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled.
In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition.
When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle().
Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue.
Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()
A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it.
Below is the KASAN splat after the out of bounds access happens:
[ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 ...
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved:
fbcon: fix integer overflow in fbcon_do_set_font
Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters.
The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.
Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.(CVE-2025-39967)
In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn->state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 </TASK>Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)
In the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"perf-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.118.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-114.0.0.118.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"perf-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-114.0.0.118.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.118.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-114.0.0.118.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:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()\n\nXen doesn\u0026apos;t offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results\nin the following warning:\n\n unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0)\n Call Trace:\n xen_read_msr+0x1e/0x30\n amd_get_mmconfig_range+0x2b/0x80\n quirk_amd_mmconfig_area+0x28/0x100\n pnp_fixup_device+0x39/0x50\n __pnp_add_device+0xf/0x150\n pnp_add_device+0x3d/0x100\n pnpacpi_add_device_handler+0x1f9/0x280\n acpi_ns_get_device_callback+0x104/0x1c0\n acpi_ns_walk_namespace+0x1d0/0x260\n acpi_get_devices+0x8a/0xb0\n pnpacpi_init+0x50/0x80\n do_one_initcall+0x46/0x2e0\n kernel_init_freeable+0x1da/0x2f0\n kernel_init+0x16/0x1b0\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1b/0x30\n\nbased on quirks for a \u0026quot;PNP0c01\u0026quot; device. Treating MMCFG as disabled is the\nright course of action, so no change is needed there.\n\nThis was most likely exposed by fixing the Xen MSR accessors to not be\nsilently-safe.(CVE-2025-21913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: Prevent possible adminq overflow/stuck condition\n\nThe pds_core\u0026apos;s adminq is protected by the adminq_lock, which prevents\nmore than 1 command to be posted onto it at any one time. This makes it\nso the client drivers cannot simultaneously post adminq commands.\nHowever, the completions happen in a different context, which means\nmultiple adminq commands can be posted sequentially and all waiting\non completion.\n\nOn the FW side, the backing adminq request queue is only 16 entries\nlong and the retry mechanism and/or overflow/stuck prevention is\nlacking. This can cause the adminq to get stuck, so commands are no\nlonger processed and completions are no longer sent by the FW.\n\nAs an initial fix, prevent more than 16 outstanding adminq commands so\nthere\u0026apos;s no way to cause the adminq from getting stuck. This works\nbecause the backing adminq request queue will never have more than 16\npending adminq commands, so it will never overflow. This is done by\nreducing the adminq depth to 16.(CVE-2025-37987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: fix NULL dereference on unbind due to stale coupling data\n\nFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs can\nlead to NULL pointer dereference when regulators are accessed post-unbind.\n\nThis can happen during runtime PM or other regulator operations that rely\non coupling metadata.\n\nFor example, on ridesx4, unbinding the \u0026apos;reg-dummy\u0026apos; platform device triggers\na panic in regulator_lock_recursive() due to stale coupling state.\n\nEnsure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().\n\nWhen the nvif_vmm_type is invalid, we will return error directly\nwithout freeing the args in nvif_vmm_ctor(), which leading a memory\nleak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: fix panic due to PSLVERR\n\nWhen the PSLVERR_RESP_EN parameter is set to 1, the device generates\nan error response if an attempt is made to read an empty RBR (Receive\nBuffer Register) while the FIFO is enabled.\n\nIn serial8250_do_startup(), calling serial_port_out(port, UART_LCR,\nUART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes\ndw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter\nfunction enables the FIFO via serial_out(p, UART_FCR, p-\u0026gt;fcr).\nExecution proceeds to the serial_port_in(port, UART_RX).\nThis satisfies the PSLVERR trigger condition.\n\nWhen another CPU (e.g., using printk()) is accessing the UART (UART\nis busy), the current CPU fails the check (value \u0026amp; ~UART_LCR_SPAR) ==\n(lcr \u0026amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter\ndw8250_force_idle().\n\nPut serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-\u0026gt;lock\nto fix this issue.\n\nPanic backtrace:\n[ 0.442336] Oops - unknown exception [#1]\n[ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a\n[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e\n...\n[ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: fix slab out-of-bounds access in mt_report_fixup()\n\nA malicious HID device can trigger a slab out-of-bounds during\nmt_report_fixup() by passing in report descriptor smaller than\n607 bytes. mt_report_fixup() attempts to patch byte offset 607\nof the descriptor with 0x25 by first checking if byte offset\n607 is 0x15 however it lacks bounds checks to verify if the\ndescriptor is big enough before conducting this check. Fix\nthis bug by ensuring the descriptor size is at least 608\nbytes before accessing it.\n\nBelow is the KASAN splat after the out of bounds access happens:\n\n[ 13.671954] ==================================================================\n[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110\n[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10\n[ 13.673297]\n[ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3\n[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04\n[ 13.673297] Call Trace:\n[ 13.673297] \u0026lt;TASK\u0026gt;\n[ 13.673297] dump_stack_lvl+0x5f/0x80\n[ 13.673297] print_report+0xd1/0x660\n[ 13.673297] kasan_report+0xe5/0x120\n[ 13.673297] __asan_report_load1_noabort+0x18/0x20\n[ 13.673297] mt_report_fixup+0x103/0x110\n[ 13.673297] hid_open_report+0x1ef/0x810\n[ 13.673297] mt_probe+0x422/0x960\n[ 13.673297] hid_device_probe+0x2e2/0x6f0\n[ 13.673297] really_probe+0x1c6/0x6b0\n[ 13.673297] __driver_probe_device+0x24f/0x310\n[ 13.673297] driver_probe_device+0x4e/0x220\n[ 13.673297] __device_attach_driver+0x169/0x320\n[ 13.673297] bus_for_each_drv+0x11d/0x1b0\n[ 13.673297] __device_attach+0x1b8/0x3e0\n[ 13.673297] device_initial_probe+0x12/0x20\n[ 13.673297] bus_probe_device+0x13d/0x180\n[ 13.673297] device_add+0xe3a/0x1670\n[ 13.673297] hid_add_device+0x31d/0xa40\n[...](CVE-2025-39806)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: fix integer overflow in fbcon_do_set_font\n\nFix integer overflow vulnerabilities in fbcon_do_set_font() where font\nsize calculations could overflow when handling user-controlled font\nparameters.\n\nThe vulnerabilities occur when:\n1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount\n multiplication with user-controlled values that can overflow.\n2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow\n3. This results in smaller allocations than expected, leading to buffer\n overflows during font data copying.\n\nAdd explicit overflow checking using check_mul_overflow() and\ncheck_add_overflow() kernel helpers to safety validate all size\ncalculations before allocation.(CVE-2025-39967)\n\nIn the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn-\u0026gt;state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 \u0026lt;/TASK\u0026gt;Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)\n\nIn the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx-\u0026gt;users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)\n\nIn the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)",
"id": "OESA-2025-2551",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2551"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37987"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40019"
}
],
"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-53168",
"CVE-2025-21913",
"CVE-2025-37987",
"CVE-2025-38668",
"CVE-2025-39679",
"CVE-2025-39724",
"CVE-2025-39806",
"CVE-2025-39898",
"CVE-2025-39967",
"CVE-2025-39982",
"CVE-2025-39993",
"CVE-2025-39998",
"CVE-2025-40019"
]
}
OESA-2025-2552 (CVE-2025-37987)
Vulnerability from osv_openeuler – Published: 2025-10-31 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:
pds_core: Prevent possible adminq overflow/stuck condition
The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion.
On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW.
As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.(CVE-2025-37987)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: fix NULL dereference on unbind due to stale coupling data
Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind.
This can happen during runtime PM or other regulator operations that rely on coupling metadata.
For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state.
Ensure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().
When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: fix panic due to PSLVERR
When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled.
In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition.
When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle().
Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue.
Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()
A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it.
Below is the KASAN splat after the out of bounds access happens:
[ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 ...
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved:
fbcon: fix integer overflow in fbcon_do_set_font
Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters.
The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.
Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.(CVE-2025-39967)
In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn->state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 </TASK>Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)
In the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)
| URL | Type | |||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"perf-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.120.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-114.0.0.120.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"perf-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-114.0.0.120.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.120.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-114.0.0.120.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\npds_core: Prevent possible adminq overflow/stuck condition\n\nThe pds_core\u0026apos;s adminq is protected by the adminq_lock, which prevents\nmore than 1 command to be posted onto it at any one time. This makes it\nso the client drivers cannot simultaneously post adminq commands.\nHowever, the completions happen in a different context, which means\nmultiple adminq commands can be posted sequentially and all waiting\non completion.\n\nOn the FW side, the backing adminq request queue is only 16 entries\nlong and the retry mechanism and/or overflow/stuck prevention is\nlacking. This can cause the adminq to get stuck, so commands are no\nlonger processed and completions are no longer sent by the FW.\n\nAs an initial fix, prevent more than 16 outstanding adminq commands so\nthere\u0026apos;s no way to cause the adminq from getting stuck. This works\nbecause the backing adminq request queue will never have more than 16\npending adminq commands, so it will never overflow. This is done by\nreducing the adminq depth to 16.(CVE-2025-37987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: fix NULL dereference on unbind due to stale coupling data\n\nFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs can\nlead to NULL pointer dereference when regulators are accessed post-unbind.\n\nThis can happen during runtime PM or other regulator operations that rely\non coupling metadata.\n\nFor example, on ridesx4, unbinding the \u0026apos;reg-dummy\u0026apos; platform device triggers\na panic in regulator_lock_recursive() due to stale coupling state.\n\nEnsure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().\n\nWhen the nvif_vmm_type is invalid, we will return error directly\nwithout freeing the args in nvif_vmm_ctor(), which leading a memory\nleak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: fix panic due to PSLVERR\n\nWhen the PSLVERR_RESP_EN parameter is set to 1, the device generates\nan error response if an attempt is made to read an empty RBR (Receive\nBuffer Register) while the FIFO is enabled.\n\nIn serial8250_do_startup(), calling serial_port_out(port, UART_LCR,\nUART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes\ndw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter\nfunction enables the FIFO via serial_out(p, UART_FCR, p-\u0026gt;fcr).\nExecution proceeds to the serial_port_in(port, UART_RX).\nThis satisfies the PSLVERR trigger condition.\n\nWhen another CPU (e.g., using printk()) is accessing the UART (UART\nis busy), the current CPU fails the check (value \u0026amp; ~UART_LCR_SPAR) ==\n(lcr \u0026amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter\ndw8250_force_idle().\n\nPut serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-\u0026gt;lock\nto fix this issue.\n\nPanic backtrace:\n[ 0.442336] Oops - unknown exception [#1]\n[ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a\n[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e\n...\n[ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: fix slab out-of-bounds access in mt_report_fixup()\n\nA malicious HID device can trigger a slab out-of-bounds during\nmt_report_fixup() by passing in report descriptor smaller than\n607 bytes. mt_report_fixup() attempts to patch byte offset 607\nof the descriptor with 0x25 by first checking if byte offset\n607 is 0x15 however it lacks bounds checks to verify if the\ndescriptor is big enough before conducting this check. Fix\nthis bug by ensuring the descriptor size is at least 608\nbytes before accessing it.\n\nBelow is the KASAN splat after the out of bounds access happens:\n\n[ 13.671954] ==================================================================\n[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110\n[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10\n[ 13.673297]\n[ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3\n[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04\n[ 13.673297] Call Trace:\n[ 13.673297] \u0026lt;TASK\u0026gt;\n[ 13.673297] dump_stack_lvl+0x5f/0x80\n[ 13.673297] print_report+0xd1/0x660\n[ 13.673297] kasan_report+0xe5/0x120\n[ 13.673297] __asan_report_load1_noabort+0x18/0x20\n[ 13.673297] mt_report_fixup+0x103/0x110\n[ 13.673297] hid_open_report+0x1ef/0x810\n[ 13.673297] mt_probe+0x422/0x960\n[ 13.673297] hid_device_probe+0x2e2/0x6f0\n[ 13.673297] really_probe+0x1c6/0x6b0\n[ 13.673297] __driver_probe_device+0x24f/0x310\n[ 13.673297] driver_probe_device+0x4e/0x220\n[ 13.673297] __device_attach_driver+0x169/0x320\n[ 13.673297] bus_for_each_drv+0x11d/0x1b0\n[ 13.673297] __device_attach+0x1b8/0x3e0\n[ 13.673297] device_initial_probe+0x12/0x20\n[ 13.673297] bus_probe_device+0x13d/0x180\n[ 13.673297] device_add+0xe3a/0x1670\n[ 13.673297] hid_add_device+0x31d/0xa40\n[...](CVE-2025-39806)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: fix integer overflow in fbcon_do_set_font\n\nFix integer overflow vulnerabilities in fbcon_do_set_font() where font\nsize calculations could overflow when handling user-controlled font\nparameters.\n\nThe vulnerabilities occur when:\n1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount\n multiplication with user-controlled values that can overflow.\n2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow\n3. This results in smaller allocations than expected, leading to buffer\n overflows during font data copying.\n\nAdd explicit overflow checking using check_mul_overflow() and\ncheck_add_overflow() kernel helpers to safety validate all size\ncalculations before allocation.(CVE-2025-39967)\n\nIn the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn-\u0026gt;state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 \u0026lt;/TASK\u0026gt;Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)\n\nIn the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx-\u0026gt;users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)\n\nIn the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)",
"id": "OESA-2025-2552",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2552"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37987"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40019"
}
],
"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-2025-37987",
"CVE-2025-38668",
"CVE-2025-39679",
"CVE-2025-39724",
"CVE-2025-39806",
"CVE-2025-39898",
"CVE-2025-39967",
"CVE-2025-39982",
"CVE-2025-39993",
"CVE-2025-39998",
"CVE-2025-40019"
]
}
OESA-2025-2554 (CVE-2022-50306)
Vulnerability from osv_openeuler – Published: 2025-10-31 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: fix potential out of bound read in ext4_fc_replay_scan()
For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.(CVE-2022-50306)
A use-after-free vulnerability in the Linux kernel s netfilter: nf_tables component can be exploited to achieve local privilege escalation.Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.(CVE-2023-4244)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: Correct devm device reference for hidinput input_dev name
Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management.
Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.(CVE-2023-53454)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix deletion race condition
System crash when using debug kernel due to link list corruption. The cause of the link list corruption is due to session deletion was allowed to queue up twice. Here's the internal trace that show the same port was allowed to double queue for deletion on different cpu.
20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1
Move the clearing/setting of deleted flag lock.(CVE-2023-53615)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix possible desc_ptr out-of-bounds accesses
Sanitize possible desc_ptr out-of-bounds accesses in ses_enclosure_data_process().(CVE-2023-53675)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a potential data corruption
We must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list. Add a call that mirrors the effect of nfs_cancel_remove_inode() for O_DIRECT.(CVE-2023-53711)
In the Linux kernel, the following vulnerability has been resolved: md: raid1: fix potential OOB in raid1_remove_disk(). If rddev->raid_disk is greater than mddev->raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows: 1) commit d17f744e883b ("md-raid10: fix KASAN warning") 2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk"). Fix this bug by checking whether the "number" variable is valid.(CVE-2023-53722)
In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)
In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.pabeni@redhat.com: fixed commit message typo
In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)
In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field &msg->msg[msg->curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 drm_display_helper
In the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st->ts_input, however, the err label can be reached before theallocated iio_dev is stored to st->ts_input. Thus callinput_free_device() on input instead of st->ts_input.(CVE-2024-57904)
In the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)
In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)
In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.kwilczynski: commit log
In the Linux kernel, the following vulnerability has been resolved:
bpf: consider that tail calls invalidate packet pointers
Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.
Making the change in bpf_helper_changes_pkt_data() automatically makes use of check_cfg() logic that computes 'changes_pkt_data' effect for global sub-programs, such that the following program could be rejected:
int tail_call(struct __sk_buff *sk)
{
bpf_tail_call_static(sk, &jmp_table, 0);
return 0;
}
SEC("tc")
int not_safe(struct __sk_buff *sk)
{
int *p = (void *)(long)sk->data;
... make p valid ...
tail_call(sk);
*p = 42; /* this is unsafe */
...
}
The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)
In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)
In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix oops when unload drivers paralleling
When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops.
But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock.
To fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)
In the Linux kernel, the following vulnerability has been resolved:
sctp: detect and prevent references to a freed transport in sendmsg
sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent.
There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf().
This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read.
This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").
Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process.
If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send.
The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).(CVE-2025-23142)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: drr: Fix double list add in class with netem as child qdisc
As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Flush gso_skb list too during ->change()
Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.
This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.(CVE-2025-37992)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.
Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.
In the case where the unconfirmed client is expiring, just fail and return the result from get_client_locked().(CVE-2025-38724)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"perf-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-287.0.0.189.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"perf-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.189.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-287.0.0.189.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: fix potential out of bound read in ext4_fc_replay_scan()\n\nFor scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain\nspace less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read\nwhen mounting corrupt file system image.\nADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this\nthree tags will read data during scan, tag length couldn\u0026apos;t less than data length\nwhich will read.(CVE-2022-50306)\n\nA use-after-free vulnerability in the Linux kernel s netfilter: nf_tables component can be exploited to achieve local privilege escalation.Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.(CVE-2023-4244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Correct devm device reference for hidinput input_dev name\n\nReference the HID device rather than the input device for the devm\nallocation of the input_dev name. Referencing the input_dev would lead to a\nuse-after-free when the input_dev was unregistered and subsequently fires a\nuevent that depends on the name. At the point of firing the uevent, the\nname would be freed by devres management.\n\nUse devm_kasprintf to simplify the logic for allocating memory and\nformatting the input_dev name string.(CVE-2023-53454)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix deletion race condition\n\nSystem crash when using debug kernel due to link list corruption. The cause\nof the link list corruption is due to session deletion was allowed to queue\nup twice. Here\u0026apos;s the internal trace that show the same port was allowed to\ndouble queue for deletion on different cpu.\n\n20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\n20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\n\nMove the clearing/setting of deleted flag lock.(CVE-2023-53615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix possible desc_ptr out-of-bounds accesses\n\nSanitize possible desc_ptr out-of-bounds accesses in\nses_enclosure_data_process().(CVE-2023-53675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a potential data corruption\n\nWe must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list.\nAdd a call that mirrors the effect of nfs_cancel_remove_inode() for O_DIRECT.(CVE-2023-53711)\n\nIn the Linux kernel, the following vulnerability has been resolved: md: raid1: fix potential OOB in raid1_remove_disk(). If rddev-\u0026gt;raid_disk is greater than mddev-\u0026gt;raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows: 1) commit d17f744e883b (\u0026quot;md-raid10: fix KASAN warning\u0026quot;) 2) commit 1ebc2cec0b7d (\u0026quot;dm raid: fix KASAN warning in raid5_remove_disk\u0026quot;). Fix this bug by checking whether the \u0026quot;number\u0026quot; variable is valid.(CVE-2023-53722)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig-\u0026gt;posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig-\u0026gt;posix_timer_id \u0026lt; 0) start = sig-\u0026gt;posix_timer_id; sig-\u0026gt;posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig-\u0026gt;posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk-\u0026gt;rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.[pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\n\nIn the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: \u0026lt;TASK\u0026gt; ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field \u0026amp;msg-\u0026gt;msg[msg-\u0026gt;curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper](CVE-2024-56616)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st-\u0026gt;ts_input, however, the err label can be reached before theallocated iio_dev is stored to st-\u0026gt;ts_input. Thus callinput_free_device() on input instead of st-\u0026gt;ts_input.(CVE-2024-57904)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)\n\nIn the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link-\u0026gt;downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log](CVE-2024-58093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: consider that tail calls invalidate packet pointers\n\nTail-called programs could execute any of the helpers that invalidate\npacket pointers. Hence, conservatively assume that each tail call\ninvalidates packet pointers.\n\nMaking the change in bpf_helper_changes_pkt_data() automatically makes\nuse of check_cfg() logic that computes \u0026apos;changes_pkt_data\u0026apos; effect for\nglobal sub-programs, such that the following program could be\nrejected:\n\n int tail_call(struct __sk_buff *sk)\n {\n \tbpf_tail_call_static(sk, \u0026amp;jmp_table, 0);\n \treturn 0;\n }\n\n SEC(\u0026quot;tc\u0026quot;)\n int not_safe(struct __sk_buff *sk)\n {\n \tint *p = (void *)(long)sk-\u0026gt;data;\n \t... make p valid ...\n \ttail_call(sk);\n \t*p = 42; /* this is unsafe */\n \t...\n }\n\nThe tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that\ncan invalidate packet pointers. Otherwise, it can\u0026apos;t be freplaced with\ntailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)\n\nIn the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)\n\nIn the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix oops when unload drivers paralleling\n\nWhen unload hclge driver, it tries to disable sriov first for each\nae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at\nthe time, because it removes all the ae_dev nodes, and it may cause\noops.\n\nBut we can\u0026apos;t simply use hnae3_common_lock for this. Because in the\nprocess flow of pci_disable_sriov(), it will trigger the remove flow\nof VF, which will also take hnae3_common_lock.\n\nTo fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere\u0026apos;s a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as \u0026quot;dead\u0026quot;. In order to do this,\nthe patch restores the \u0026quot;dead\u0026quot; bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e (\u0026quot;sctp: remove the dead field of sctp_transport\u0026quot;).\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).(CVE-2025-23142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too\n\nSimilarly to the previous patch, we need to safe guard hfsc_dequeue()\ntoo. But for this one, we don\u0026apos;t have a reliable reproducer.(CVE-2025-37823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: drr: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of drr, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether the\nclass was already added to the active_list (cl_is_active) before adding\nto the list to cover for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Flush gso_skb list too during -\u0026gt;change()\n\nPreviously, when reducing a qdisc\u0026apos;s limit via the -\u0026gt;change() operation, only\nthe main skb queue was trimmed, potentially leaving packets in the gso_skb\nlist. This could result in NULL pointer dereference when we only check\nsch-\u0026gt;limit against sch-\u0026gt;q.qlen.\n\nThis patch introduces a new helper, qdisc_dequeue_internal(), which ensures\nboth the gso_skb list and the main queue are properly flushed when trimming\nexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)\nare updated to use this helper in their -\u0026gt;change() routines.(CVE-2025-37992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()\n\nLei Lu recently reported that nfsd4_setclientid_confirm() did not check\nthe return value from get_client_locked(). a SETCLIENTID_CONFIRM could\nrace with a confirmed client expiring and fail to get a reference. That\ncould later lead to a UAF.\n\nFix this by getting a reference early in the case where there is an\nextant confirmed client. If that fails then treat it as if there were no\nconfirmed client found at all.\n\nIn the case where the unconfirmed client is expiring, just fail and\nreturn the result from get_client_locked().(CVE-2025-38724)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)",
"id": "OESA-2025-2554",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2554"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50306"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53454"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50306",
"CVE-2023-4244",
"CVE-2023-53454",
"CVE-2023-53615",
"CVE-2023-53675",
"CVE-2023-53711",
"CVE-2023-53722",
"CVE-2023-53728",
"CVE-2024-50210",
"CVE-2024-53168",
"CVE-2024-53214",
"CVE-2024-56602",
"CVE-2024-56616",
"CVE-2024-57904",
"CVE-2024-57906",
"CVE-2024-57931",
"CVE-2024-58052",
"CVE-2024-58093",
"CVE-2024-58237",
"CVE-2025-21665",
"CVE-2025-21772",
"CVE-2025-21802",
"CVE-2025-23142",
"CVE-2025-37823",
"CVE-2025-37915",
"CVE-2025-37992",
"CVE-2025-38724",
"CVE-2025-39898",
"CVE-2025-39971",
"CVE-2025-39998"
]
}
OESA-2025-2555 (CVE-2022-50306)
Vulnerability from osv_openeuler – Published: 2025-10-31 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: fix potential out of bound read in ext4_fc_replay_scan()
For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.(CVE-2022-50306)
In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)
In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.pabeni@redhat.com: fixed commit message typo
In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)
In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field &msg->msg[msg->curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 drm_display_helper
In the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st->ts_input, however, the err label can be reached before theallocated iio_dev is stored to st->ts_input. Thus callinput_free_device() on input instead of st->ts_input.(CVE-2024-57904)
In the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)
In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)
In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.kwilczynski: commit log
In the Linux kernel, the following vulnerability has been resolved:
bpf: consider that tail calls invalidate packet pointers
Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.
Making the change in bpf_helper_changes_pkt_data() automatically makes use of check_cfg() logic that computes 'changes_pkt_data' effect for global sub-programs, such that the following program could be rejected:
int tail_call(struct __sk_buff *sk)
{
bpf_tail_call_static(sk, &jmp_table, 0);
return 0;
}
SEC("tc")
int not_safe(struct __sk_buff *sk)
{
int *p = (void *)(long)sk->data;
... make p valid ...
tail_call(sk);
*p = 42; /* this is unsafe */
...
}
The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)
In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)
In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix oops when unload drivers paralleling
When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops.
But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock.
To fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)
In the Linux kernel, the following vulnerability has been resolved:
sctp: detect and prevent references to a freed transport in sendmsg
sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent.
There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf().
This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read.
This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").
Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process.
If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send.
The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).(CVE-2025-23142)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: drr: Fix double list add in class with netem as child qdisc
As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Flush gso_skb list too during ->change()
Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.
This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.(CVE-2025-37992)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.
Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.
In the case where the unconfirmed client is expiring, just fail and return the result from get_client_locked().(CVE-2025-38724)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"perf-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-287.0.0.190.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"perf-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-287.0.0.190.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential out of bound read in ext4_fc_replay_scan()\n\nFor scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain\nspace less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read\nwhen mounting corrupt file system image.\nADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this\nthree tags will read data during scan, tag length couldn\u0026apos;t less than data length\nwhich will read.(CVE-2022-50306)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig-\u0026gt;posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig-\u0026gt;posix_timer_id \u0026lt; 0) start = sig-\u0026gt;posix_timer_id; sig-\u0026gt;posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig-\u0026gt;posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk-\u0026gt;rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.[pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\n\nIn the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: \u0026lt;TASK\u0026gt; ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field \u0026amp;msg-\u0026gt;msg[msg-\u0026gt;curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper](CVE-2024-56616)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st-\u0026gt;ts_input, however, the err label can be reached before theallocated iio_dev is stored to st-\u0026gt;ts_input. Thus callinput_free_device() on input instead of st-\u0026gt;ts_input.(CVE-2024-57904)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)\n\nIn the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link-\u0026gt;downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log](CVE-2024-58093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: consider that tail calls invalidate packet pointers\n\nTail-called programs could execute any of the helpers that invalidate\npacket pointers. Hence, conservatively assume that each tail call\ninvalidates packet pointers.\n\nMaking the change in bpf_helper_changes_pkt_data() automatically makes\nuse of check_cfg() logic that computes \u0026apos;changes_pkt_data\u0026apos; effect for\nglobal sub-programs, such that the following program could be\nrejected:\n\n int tail_call(struct __sk_buff *sk)\n {\n \tbpf_tail_call_static(sk, \u0026amp;jmp_table, 0);\n \treturn 0;\n }\n\n SEC(\u0026quot;tc\u0026quot;)\n int not_safe(struct __sk_buff *sk)\n {\n \tint *p = (void *)(long)sk-\u0026gt;data;\n \t... make p valid ...\n \ttail_call(sk);\n \t*p = 42; /* this is unsafe */\n \t...\n }\n\nThe tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that\ncan invalidate packet pointers. Otherwise, it can\u0026apos;t be freplaced with\ntailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)\n\nIn the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)\n\nIn the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix oops when unload drivers paralleling\n\nWhen unload hclge driver, it tries to disable sriov first for each\nae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at\nthe time, because it removes all the ae_dev nodes, and it may cause\noops.\n\nBut we can\u0026apos;t simply use hnae3_common_lock for this. Because in the\nprocess flow of pci_disable_sriov(), it will trigger the remove flow\nof VF, which will also take hnae3_common_lock.\n\nTo fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere\u0026apos;s a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as \u0026quot;dead\u0026quot;. In order to do this,\nthe patch restores the \u0026quot;dead\u0026quot; bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e (\u0026quot;sctp: remove the dead field of sctp_transport\u0026quot;).\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).(CVE-2025-23142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too\n\nSimilarly to the previous patch, we need to safe guard hfsc_dequeue()\ntoo. But for this one, we don\u0026apos;t have a reliable reproducer.(CVE-2025-37823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: drr: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of drr, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether the\nclass was already added to the active_list (cl_is_active) before adding\nto the list to cover for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Flush gso_skb list too during -\u0026gt;change()\n\nPreviously, when reducing a qdisc\u0026apos;s limit via the -\u0026gt;change() operation, only\nthe main skb queue was trimmed, potentially leaving packets in the gso_skb\nlist. This could result in NULL pointer dereference when we only check\nsch-\u0026gt;limit against sch-\u0026gt;q.qlen.\n\nThis patch introduces a new helper, qdisc_dequeue_internal(), which ensures\nboth the gso_skb list and the main queue are properly flushed when trimming\nexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)\nare updated to use this helper in their -\u0026gt;change() routines.(CVE-2025-37992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()\n\nLei Lu recently reported that nfsd4_setclientid_confirm() did not check\nthe return value from get_client_locked(). a SETCLIENTID_CONFIRM could\nrace with a confirmed client expiring and fail to get a reference. That\ncould later lead to a UAF.\n\nFix this by getting a reference early in the case where there is an\nextant confirmed client. If that fails then treat it as if there were no\nconfirmed client found at all.\n\nIn the case where the unconfirmed client is expiring, just fail and\nreturn the result from get_client_locked().(CVE-2025-38724)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)",
"id": "OESA-2025-2555",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2555"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50306"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50306",
"CVE-2023-53728",
"CVE-2024-50210",
"CVE-2024-53168",
"CVE-2024-53214",
"CVE-2024-56602",
"CVE-2024-56616",
"CVE-2024-57904",
"CVE-2024-57906",
"CVE-2024-57931",
"CVE-2024-58052",
"CVE-2024-58093",
"CVE-2024-58237",
"CVE-2025-21665",
"CVE-2025-21772",
"CVE-2025-21802",
"CVE-2025-23142",
"CVE-2025-37823",
"CVE-2025-37915",
"CVE-2025-37992",
"CVE-2025-38724",
"CVE-2025-39898",
"CVE-2025-39971",
"CVE-2025-39998"
]
}
OESA-2025-2556 (CVE-2024-53168)
Vulnerability from osv_openeuler – Published: 2025-10-31 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:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:
x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()
Xen doesn't offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results in the following warning:
unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0) Call Trace: xen_read_msr+0x1e/0x30 amd_get_mmconfig_range+0x2b/0x80 quirk_amd_mmconfig_area+0x28/0x100 pnp_fixup_device+0x39/0x50 __pnp_add_device+0xf/0x150 pnp_add_device+0x3d/0x100 pnpacpi_add_device_handler+0x1f9/0x280 acpi_ns_get_device_callback+0x104/0x1c0 acpi_ns_walk_namespace+0x1d0/0x260 acpi_get_devices+0x8a/0xb0 pnpacpi_init+0x50/0x80 do_one_initcall+0x46/0x2e0 kernel_init_freeable+0x1da/0x2f0 kernel_init+0x16/0x1b0 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1b/0x30
based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.
This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.(CVE-2025-21913)
In the Linux kernel, the following vulnerability has been resolved:
pds_core: Prevent possible adminq overflow/stuck condition
The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion.
On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW.
As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16.(CVE-2025-37987)
In the Linux kernel, the following vulnerability has been resolved:
module: ensure that kobject_put() is safe for module type kobjects
In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.(CVE-2025-37995)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: fix NULL dereference on unbind due to stale coupling data
Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind.
This can happen during runtime PM or other regulator operations that rely on coupling metadata.
For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state.
Ensure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().
When the nvif_vmm_type is invalid, we will return error directly without freeing the args in nvif_vmm_ctor(), which leading a memory leak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)
In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: fix panic due to PSLVERR
When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled.
In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition.
When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle().
Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue.
Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()
A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it.
Below is the KASAN splat after the out of bounds access happens:
[ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 ...
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved:
fbcon: fix integer overflow in fbcon_do_set_font
Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters.
The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.
Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.(CVE-2025-39967)
In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn->state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 </TASK>Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)
In the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-source-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"perf-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"python3-perf-6.6.0-114.0.0.106.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.106.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-114.0.0.106.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-source-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"perf-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"python3-perf-6.6.0-114.0.0.106.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-114.0.0.106.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-114.0.0.106.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:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()\n\nXen doesn\u0026apos;t offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results\nin the following warning:\n\n unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0)\n Call Trace:\n xen_read_msr+0x1e/0x30\n amd_get_mmconfig_range+0x2b/0x80\n quirk_amd_mmconfig_area+0x28/0x100\n pnp_fixup_device+0x39/0x50\n __pnp_add_device+0xf/0x150\n pnp_add_device+0x3d/0x100\n pnpacpi_add_device_handler+0x1f9/0x280\n acpi_ns_get_device_callback+0x104/0x1c0\n acpi_ns_walk_namespace+0x1d0/0x260\n acpi_get_devices+0x8a/0xb0\n pnpacpi_init+0x50/0x80\n do_one_initcall+0x46/0x2e0\n kernel_init_freeable+0x1da/0x2f0\n kernel_init+0x16/0x1b0\n ret_from_fork+0x30/0x50\n ret_from_fork_asm+0x1b/0x30\n\nbased on quirks for a \u0026quot;PNP0c01\u0026quot; device. Treating MMCFG as disabled is the\nright course of action, so no change is needed there.\n\nThis was most likely exposed by fixing the Xen MSR accessors to not be\nsilently-safe.(CVE-2025-21913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: Prevent possible adminq overflow/stuck condition\n\nThe pds_core\u0026apos;s adminq is protected by the adminq_lock, which prevents\nmore than 1 command to be posted onto it at any one time. This makes it\nso the client drivers cannot simultaneously post adminq commands.\nHowever, the completions happen in a different context, which means\nmultiple adminq commands can be posted sequentially and all waiting\non completion.\n\nOn the FW side, the backing adminq request queue is only 16 entries\nlong and the retry mechanism and/or overflow/stuck prevention is\nlacking. This can cause the adminq to get stuck, so commands are no\nlonger processed and completions are no longer sent by the FW.\n\nAs an initial fix, prevent more than 16 outstanding adminq commands so\nthere\u0026apos;s no way to cause the adminq from getting stuck. This works\nbecause the backing adminq request queue will never have more than 16\npending adminq commands, so it will never overflow. This is done by\nreducing the adminq depth to 16.(CVE-2025-37987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmodule: ensure that kobject_put() is safe for module type kobjects\n\nIn \u0026apos;lookup_or_create_module_kobject()\u0026apos;, an internal kobject is created\nusing \u0026apos;module_ktype\u0026apos;. So call to \u0026apos;kobject_put()\u0026apos; on error handling\npath causes an attempt to use an uninitialized completion pointer in\n\u0026apos;module_kobject_release()\u0026apos;. In this scenario, we just want to release\nkobject without an extra synchronization required for a regular module\nunloading process, so adding an extra check whether \u0026apos;complete()\u0026apos; is\nactually required makes \u0026apos;kobject_put()\u0026apos; safe.(CVE-2025-37995)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: fix NULL dereference on unbind due to stale coupling data\n\nFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs can\nlead to NULL pointer dereference when regulators are accessed post-unbind.\n\nThis can happen during runtime PM or other regulator operations that rely\non coupling metadata.\n\nFor example, on ridesx4, unbinding the \u0026apos;reg-dummy\u0026apos; platform device triggers\na panic in regulator_lock_recursive() due to stale coupling state.\n\nEnsure n_coupled is set to 0 to prevent access to invalid pointers.(CVE-2025-38668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().\n\nWhen the nvif_vmm_type is invalid, we will return error directly\nwithout freeing the args in nvif_vmm_ctor(), which leading a memory\nleak. Fix it by setting the ret -EINVAL and goto done.(CVE-2025-39679)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: fix panic due to PSLVERR\n\nWhen the PSLVERR_RESP_EN parameter is set to 1, the device generates\nan error response if an attempt is made to read an empty RBR (Receive\nBuffer Register) while the FIFO is enabled.\n\nIn serial8250_do_startup(), calling serial_port_out(port, UART_LCR,\nUART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes\ndw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter\nfunction enables the FIFO via serial_out(p, UART_FCR, p-\u0026gt;fcr).\nExecution proceeds to the serial_port_in(port, UART_RX).\nThis satisfies the PSLVERR trigger condition.\n\nWhen another CPU (e.g., using printk()) is accessing the UART (UART\nis busy), the current CPU fails the check (value \u0026amp; ~UART_LCR_SPAR) ==\n(lcr \u0026amp; ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter\ndw8250_force_idle().\n\nPut serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port-\u0026gt;lock\nto fix this issue.\n\nPanic backtrace:\n[ 0.442336] Oops - unknown exception [#1]\n[ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a\n[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e\n...\n[ 0.442416] console_on_rootfs+0x26/0x70(CVE-2025-39724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: fix slab out-of-bounds access in mt_report_fixup()\n\nA malicious HID device can trigger a slab out-of-bounds during\nmt_report_fixup() by passing in report descriptor smaller than\n607 bytes. mt_report_fixup() attempts to patch byte offset 607\nof the descriptor with 0x25 by first checking if byte offset\n607 is 0x15 however it lacks bounds checks to verify if the\ndescriptor is big enough before conducting this check. Fix\nthis bug by ensuring the descriptor size is at least 608\nbytes before accessing it.\n\nBelow is the KASAN splat after the out of bounds access happens:\n\n[ 13.671954] ==================================================================\n[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110\n[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10\n[ 13.673297]\n[ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3\n[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04\n[ 13.673297] Call Trace:\n[ 13.673297] \u0026lt;TASK\u0026gt;\n[ 13.673297] dump_stack_lvl+0x5f/0x80\n[ 13.673297] print_report+0xd1/0x660\n[ 13.673297] kasan_report+0xe5/0x120\n[ 13.673297] __asan_report_load1_noabort+0x18/0x20\n[ 13.673297] mt_report_fixup+0x103/0x110\n[ 13.673297] hid_open_report+0x1ef/0x810\n[ 13.673297] mt_probe+0x422/0x960\n[ 13.673297] hid_device_probe+0x2e2/0x6f0\n[ 13.673297] really_probe+0x1c6/0x6b0\n[ 13.673297] __driver_probe_device+0x24f/0x310\n[ 13.673297] driver_probe_device+0x4e/0x220\n[ 13.673297] __device_attach_driver+0x169/0x320\n[ 13.673297] bus_for_each_drv+0x11d/0x1b0\n[ 13.673297] __device_attach+0x1b8/0x3e0\n[ 13.673297] device_initial_probe+0x12/0x20\n[ 13.673297] bus_probe_device+0x13d/0x180\n[ 13.673297] device_add+0xe3a/0x1670\n[ 13.673297] hid_add_device+0x31d/0xa40\n[...](CVE-2025-39806)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: fix integer overflow in fbcon_do_set_font\n\nFix integer overflow vulnerabilities in fbcon_do_set_font() where font\nsize calculations could overflow when handling user-controlled font\nparameters.\n\nThe vulnerabilities occur when:\n1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount\n multiplication with user-controlled values that can overflow.\n2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow\n3. This results in smaller allocations than expected, leading to buffer\n overflows during font data copying.\n\nAdd explicit overflow checking using check_mul_overflow() and\ncheck_add_overflow() kernel helpers to safety validate all size\ncalculations before allocation.(CVE-2025-39967)\n\nIn the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_syncThis fixes the following UFA in hci_acl_create_conn_sync where aconnection still pending is command submission (conn-\u0026gt;state == BT_OPEN)maybe freed, also since this also can happen with the likes ofhci_le_create_conn_sync fix it as well:BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014Workqueue: hci3 hci_cmd_sync_workCall Trace: \u0026lt;TASK\u0026gt; dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 \u0026lt;/TASK\u0026gt;Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour---truncated---(CVE-2025-39982)\n\nIn the Linux kernel, the iMON driver has a race condition vulnerability. The issue stems from imon_disconnect() improperly releasing the usb_device reference without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx-\u0026gt;users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. This can lead to a use-after-free (UAF) of the usb_device pointer if vfd_write or other operations are still in progress after disconnect.(CVE-2025-39993)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)\n\nIn the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit s also checked for decryption and in-place encryption.(CVE-2025-40019)",
"id": "OESA-2025-2556",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37987"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39993"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40019"
}
],
"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-53168",
"CVE-2025-21913",
"CVE-2025-37987",
"CVE-2025-37995",
"CVE-2025-38668",
"CVE-2025-39679",
"CVE-2025-39724",
"CVE-2025-39806",
"CVE-2025-39898",
"CVE-2025-39967",
"CVE-2025-39982",
"CVE-2025-39993",
"CVE-2025-39998",
"CVE-2025-40019"
]
}
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.