Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-50279 (GCVE-0-2024-50279)
Vulnerability from cvelistv5 – Published: 2024-11-19 01:30 – Updated: 2026-05-11 20:49- CWE-125 - Out-of-bounds Read
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < 4fa4feb873cea0e9d6ff883b37cca6f33169d8b4
(git)
Affected: f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < 8501e38dc9e0060814c4085815fc83da3e6d43bf (git) Affected: f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < ee1f74925717ab36f6a091104c170639501ce818 (git) Affected: f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f (git) Affected: f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < 56507203e1b6127967ec2b51fb0b23a0d4af1334 (git) Affected: f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < e57648ce325fa405fe6bbd0e6a618ced7c301a2d (git) Affected: f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < 3b02c40ff10fdf83cc545850db208de855ebe22c (git) Affected: f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 , < 792227719725497ce10a8039803bec13f89f8910 (git) |
guessed | |
| Linux | Linux |
Affected:
3.13
Unaffected: 0 , < 3.13 (semver) Unaffected: 4.19.324 , ≤ 4.19.* (semver) Unaffected: 5.4.286 , ≤ 5.4.* (semver) Unaffected: 5.10.230 , ≤ 5.10.* (semver) Unaffected: 5.15.172 , ≤ 5.15.* (semver) Unaffected: 6.1.117 , ≤ 6.1.* (semver) Unaffected: 6.6.61 , ≤ 6.6.* (semver) Unaffected: 6.11.8 , ≤ 6.11.* (semver) Unaffected: 6.12 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-50279",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:14:43.545051Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T20:17:22.379Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:27:58.416Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4fa4feb873cea0e9d6ff883b37cca6f33169d8b4",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "8501e38dc9e0060814c4085815fc83da3e6d43bf",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ee1f74925717ab36f6a091104c170639501ce818",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "56507203e1b6127967ec2b51fb0b23a0d4af1334",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "e57648ce325fa405fe6bbd0e6a618ced7c301a2d",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "3b02c40ff10fdf83cc545850db208de855ebe22c",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "792227719725497ce10a8039803bec13f89f8910",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.13"
},
{
"lessThan": "3.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.324",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.286",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.230",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.172",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.61",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.324",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.286",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.230",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.172",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.117",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.61",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.8",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "3.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"\ndmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\"\ndmsetup create corig --table \"0 524288 linear /dev/sdc 262144\"\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\"\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u003effffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:49:03.406Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4"
},
{
"url": "https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf"
},
{
"url": "https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818"
},
{
"url": "https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f"
},
{
"url": "https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334"
},
{
"url": "https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d"
},
{
"url": "https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c"
},
{
"url": "https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910"
}
],
"title": "dm cache: fix out-of-bounds access to the dirty bitset when resizing",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-50279",
"datePublished": "2024-11-19T01:30:20.712Z",
"dateReserved": "2024-10-21T19:36:19.983Z",
"dateUpdated": "2026-05-11T20:49:03.406Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-50279",
"date": "2026-09-18",
"epss": "0.00262",
"percentile": "0.18382"
},
"microsoft_vex": {
"current_release_date": "2026-02-19T01:15:57.000Z",
"cve": "CVE-2024-50279",
"id": "msrc_CVE-2024-50279",
"initial_release_date": "2024-11-02T00:00:00.000Z",
"product_status:fixed": "3",
"product_status:known_affected": "3",
"product_status:known_not_affected": "1",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "dm cache: fix out-of-bounds access to the dirty bitset when resizing",
"url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-50279.json",
"version": "3"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4fa4feb873cea0e9d6ff883b37cca6f33169d8b4",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "8501e38dc9e0060814c4085815fc83da3e6d43bf",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ee1f74925717ab36f6a091104c170639501ce818",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "56507203e1b6127967ec2b51fb0b23a0d4af1334",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "e57648ce325fa405fe6bbd0e6a618ced7c301a2d",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "3b02c40ff10fdf83cc545850db208de855ebe22c",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "792227719725497ce10a8039803bec13f89f8910",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.13"
},
{
"lessThan": "3.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.324",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.286",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.230",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.172",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.61",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F34367D-A869-4C97-A01F-F5209F24FC10",
"versionEndExcluding": "4.19.324",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "9952C897-8A61-4D4B-9D6D-7D063E9EA15E",
"versionEndExcluding": "5.4.286",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BF5B32D0-72C9-41C3-A0BB-D4946153C134",
"versionEndExcluding": "5.10.230",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "88812664-4296-42AC-AE0F-ED71086C1BB1",
"versionEndExcluding": "5.15.172",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0DD7F755-2F6B-4707-8973-78496AD5AA8E",
"versionEndExcluding": "6.1.117",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "630ED7EB-C97E-4435-B884-1E309E40D6F3",
"versionEndExcluding": "6.6.61",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0BD000F7-3DAD-4DD3-8906-98EA1EC67E95",
"versionEndExcluding": "6.11.8",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*",
"matchCriteriaId": "7F361E1D-580F-4A2D-A509-7615F73167A1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*",
"matchCriteriaId": "925478D0-3E3D-4E6F-ACD5-09F28D5DF82C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*",
"matchCriteriaId": "3C95E234-D335-4B6C-96BF-E2CEBD8654ED",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*",
"matchCriteriaId": "E0F717D8-3014-4F84-8086-0124B2111379",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc5:*:*:*:*:*:*",
"matchCriteriaId": "24DBE6C7-2AAE-4818-AED2-E131F153D2FA",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc6:*:*:*:*:*:*",
"matchCriteriaId": "24B88717-53F5-42AA-9B72-14C707639E3F",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"\ndmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\"\ndmsetup create corig --table \"0 524288 linear /dev/sdc 262144\"\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\"\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u003effffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm cache: corrige el acceso fuera de los l\u00edmites al conjunto de bits sucio al cambiar el tama\u00f1o dm-cache verifica los bits sucios de los bloques de cach\u00e9 que se deben descartar al reducir el dispositivo r\u00e1pido, pero un error de \u00edndice en la iteraci\u00f3n del conjunto de bits provoca un acceso fuera de los l\u00edmites. Reproducir los pasos: 1. crear un dispositivo de cach\u00e9 de 1024 bloques de cach\u00e9 (128 bytes de bitset sucio) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. reducir el dispositivo r\u00e1pido a 512 bloques de cach\u00e9, lo que activa el acceso fuera de los l\u00edmites al bitset sucio. bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN informa: ERROR: KASAN: vmalloc-out-of-bounds en cache_preresume+0x269/0x7b0 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffffc900000f3080 por la tarea dmsetup/131 (...snip...) La direcci\u00f3n con errores pertenece al mapeo virtual en [ffffc900000f3000, ffffc900000f5000) creado por: cache_ctr+0x176a/0x35f0 (...snip...) Estado de la memoria alrededor de la direcci\u00f3n con errores: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 ..."
}
],
"id": "CVE-2024-50279",
"lastModified": "2026-06-17T08:04:05.377",
"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": "nvd@nist.gov",
"type": "Primary"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-50279",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:14:43.545051Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-11-19T02:16:30.210",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2025-11-21T14:13:34+00:00",
"cve": "CVE-2024-50279",
"id": "CVE-2024-50279",
"initial_release_date": "2024-11-19T00:00:00+00:00",
"product_status:known_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: dm cache: fix out-of-bounds access to the dirty bitset when resizing",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-50279.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:27:58.416Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-50279",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:14:43.545051Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T15:26:39.292Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4fa4feb873cea0e9d6ff883b37cca6f33169d8b4",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "8501e38dc9e0060814c4085815fc83da3e6d43bf",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ee1f74925717ab36f6a091104c170639501ce818",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "56507203e1b6127967ec2b51fb0b23a0d4af1334",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "e57648ce325fa405fe6bbd0e6a618ced7c301a2d",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "3b02c40ff10fdf83cc545850db208de855ebe22c",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "792227719725497ce10a8039803bec13f89f8910",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.13"
},
{
"lessThan": "3.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.324",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.286",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.230",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.172",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.61",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.324",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.286",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.230",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.172",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.117",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.61",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.8",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12",
"versionStartIncluding": "3.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"\ndmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\"\ndmsetup create corig --table \"0 524288 linear /dev/sdc 262144\"\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\"\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u003effffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented."
}
],
"providerMetadata": {
"dateUpdated": "2025-05-04T09:50:36.310Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4"
},
{
"url": "https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf"
},
{
"url": "https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818"
},
{
"url": "https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f"
},
{
"url": "https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334"
},
{
"url": "https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d"
},
{
"url": "https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c"
},
{
"url": "https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910"
}
],
"title": "dm cache: fix out-of-bounds access to the dirty bitset when resizing",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-50279",
"datePublished": "2024-11-19T01:30:20.712Z",
"dateReserved": "2024-10-21T19:36:19.983Z",
"dateUpdated": "2025-11-03T22:27:58.416Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2025-AVI-1032
Vulnerability from certfr_avis - Published: 2025-11-21 - Updated: 2025-11-21
De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Desktop 15 SP6 | ||
| SUSE | N/A | Public Cloud Module 15-SP7 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.3 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP7 | ||
| SUSE | N/A | SUSE Manager Proxy 4.3 | ||
| SUSE | N/A | Basesystem Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP4 | ||
| SUSE | N/A | Public Cloud Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro for Rancher 5.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP4 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.3 | ||
| SUSE | N/A | openSUSE Leap 15.4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP7 | ||
| SUSE | N/A | openSUSE Leap 15.5 | ||
| SUSE | N/A | SUSE Manager Server 4.3 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP6 | ||
| SUSE | N/A | Legacy Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 12-SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP7 | ||
| SUSE | N/A | SUSE Linux Enterprise Live Patching 15-SP7 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 LTSS | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.2 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP6 | ||
| SUSE | N/A | SUSE Manager Proxy 4.3 LTS | ||
| SUSE | N/A | openSUSE Leap 15.6 | ||
| SUSE | N/A | SUSE Manager Server 4.3 LTS | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 | ||
| SUSE | N/A | SUSE Linux Enterprise Real Time 15 SP4 | ||
| SUSE | N/A | SUSE Manager Retail Branch Server 4.3 LTS | ||
| SUSE | N/A | SUSE Linux Enterprise Workstation Extension 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 12 SP5 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.4 | ||
| SUSE | N/A | SUSE Linux Enterprise High Availability Extension 15 SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server for SAP Applications 15 SP6 | ||
| SUSE | N/A | Development Tools Module 15-SP6 | ||
| SUSE | N/A | SUSE Linux Enterprise Server 15 SP6 | ||
| SUSE | N/A | SUSE Real Time Module 15-SP7 | ||
| SUSE | N/A | SUSE Linux Enterprise Micro 5.5 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Desktop 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Public Cloud Module 15-SP7",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP7",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Basesystem Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Public Cloud Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro for Rancher 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP7",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.3",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Legacy Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 12-SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP7",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Live Patching 15-SP7",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4 LTSS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Proxy 4.3 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "openSUSE Leap 15.6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Server 4.3 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Performance Computing LTSS 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Real Time 15 SP4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Manager Retail Branch Server 4.3 LTS",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Workstation Extension 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 12 SP5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.4",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise High Availability Extension 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server for SAP Applications 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "Development Tools Module 15-SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Server 15 SP6",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Real Time Module 15-SP7",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"scada": false
}
}
},
{
"description": "SUSE Linux Enterprise Micro 5.5",
"product": {
"name": "N/A",
"vendor": {
"name": "SUSE",
"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-2022-43945",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43945"
},
{
"name": "CVE-2023-31248",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31248"
},
{
"name": "CVE-2023-3772",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3772"
},
{
"name": "CVE-2023-42753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42753"
},
{
"name": "CVE-2023-39197",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39197"
},
{
"name": "CVE-2024-26584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26584"
},
{
"name": "CVE-2024-58240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58240"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-38680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38680"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2025-38685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38685"
},
{
"name": "CVE-2025-38687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38687"
},
{
"name": "CVE-2025-38691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38691"
},
{
"name": "CVE-2025-38693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38693"
},
{
"name": "CVE-2025-38694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38694"
},
{
"name": "CVE-2025-38695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38695"
},
{
"name": "CVE-2025-38697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38697"
},
{
"name": "CVE-2025-38698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38698"
},
{
"name": "CVE-2025-38699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38699"
},
{
"name": "CVE-2025-38700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38700"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2025-38706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38706"
},
{
"name": "CVE-2025-38712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38712"
},
{
"name": "CVE-2025-38713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38713"
},
{
"name": "CVE-2025-38714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38714"
},
{
"name": "CVE-2025-38715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38715"
},
{
"name": "CVE-2025-38724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38724"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2025-38729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38729"
},
{
"name": "CVE-2025-38734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38734"
},
{
"name": "CVE-2025-38735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38735"
},
{
"name": "CVE-2025-38736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38736"
},
{
"name": "CVE-2025-39673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39673"
},
{
"name": "CVE-2025-39675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39675"
},
{
"name": "CVE-2025-39676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39676"
},
{
"name": "CVE-2025-39679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39679"
},
{
"name": "CVE-2025-39683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39683"
},
{
"name": "CVE-2025-39684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39684"
},
{
"name": "CVE-2025-39685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39685"
},
{
"name": "CVE-2025-39686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39686"
},
{
"name": "CVE-2025-39693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39693"
},
{
"name": "CVE-2025-39694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39694"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2025-39701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39701"
},
{
"name": "CVE-2025-39702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39702"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2025-39709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39709"
},
{
"name": "CVE-2025-39710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39710"
},
{
"name": "CVE-2025-39713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39713"
},
{
"name": "CVE-2025-39714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39714"
},
{
"name": "CVE-2025-39719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39719"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2025-39724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39724"
},
{
"name": "CVE-2025-39742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39742"
},
{
"name": "CVE-2025-39743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39743"
},
{
"name": "CVE-2025-39751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39751"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-39757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39757"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-39772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39772"
},
{
"name": "CVE-2025-39783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39783"
},
{
"name": "CVE-2025-39790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39790"
},
{
"name": "CVE-2025-39794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39794"
},
{
"name": "CVE-2025-39798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39798"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2025-39801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39801"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39810"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-39832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39832"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2025-39849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39849"
},
{
"name": "CVE-2025-39850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39850"
},
{
"name": "CVE-2025-39851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39851"
},
{
"name": "CVE-2025-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-39854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39854"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-39861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39861"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-38718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38718"
},
{
"name": "CVE-2025-39730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39730"
},
{
"name": "CVE-2025-39761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39761"
},
{
"name": "CVE-2023-53305",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53305"
},
{
"name": "CVE-2022-50327",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50327"
},
{
"name": "CVE-2025-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38539"
},
{
"name": "CVE-2025-38653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38653"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-39870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39870"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-39881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39881"
},
{
"name": "CVE-2025-39891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39891"
},
{
"name": "CVE-2025-39902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39902"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-39920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39920"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2022-50252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50252"
},
{
"name": "CVE-2022-50386",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50386"
},
{
"name": "CVE-2022-50388",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50388"
},
{
"name": "CVE-2022-50423",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50423"
},
{
"name": "CVE-2022-50432",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50432"
},
{
"name": "CVE-2023-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53147"
},
{
"name": "CVE-2023-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53148"
},
{
"name": "CVE-2023-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53150"
},
{
"name": "CVE-2023-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53151"
},
{
"name": "CVE-2023-53152",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53152"
},
{
"name": "CVE-2023-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53165"
},
{
"name": "CVE-2023-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53167"
},
{
"name": "CVE-2023-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53170"
},
{
"name": "CVE-2023-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53174"
},
{
"name": "CVE-2023-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53175"
},
{
"name": "CVE-2023-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53177"
},
{
"name": "CVE-2023-53179",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53179"
},
{
"name": "CVE-2023-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53180"
},
{
"name": "CVE-2023-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53181"
},
{
"name": "CVE-2023-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53183"
},
{
"name": "CVE-2023-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53184"
},
{
"name": "CVE-2023-53185",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53185"
},
{
"name": "CVE-2023-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53187"
},
{
"name": "CVE-2023-53189",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53189"
},
{
"name": "CVE-2023-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53192"
},
{
"name": "CVE-2023-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53195"
},
{
"name": "CVE-2023-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53196"
},
{
"name": "CVE-2023-53201",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53201"
},
{
"name": "CVE-2023-53204",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53204"
},
{
"name": "CVE-2023-53205",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53205"
},
{
"name": "CVE-2023-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53206"
},
{
"name": "CVE-2023-53207",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53207"
},
{
"name": "CVE-2023-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53208"
},
{
"name": "CVE-2023-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53209"
},
{
"name": "CVE-2023-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53210"
},
{
"name": "CVE-2023-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53215"
},
{
"name": "CVE-2023-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53217"
},
{
"name": "CVE-2023-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53220"
},
{
"name": "CVE-2023-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53221"
},
{
"name": "CVE-2023-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53222"
},
{
"name": "CVE-2023-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53226"
},
{
"name": "CVE-2023-53230",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53230"
},
{
"name": "CVE-2023-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53231"
},
{
"name": "CVE-2023-53235",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53235"
},
{
"name": "CVE-2023-53238",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53238"
},
{
"name": "CVE-2023-53243",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53243"
},
{
"name": "CVE-2023-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53245"
},
{
"name": "CVE-2023-53247",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53247"
},
{
"name": "CVE-2023-53248",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53248"
},
{
"name": "CVE-2023-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53249"
},
{
"name": "CVE-2023-53251",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53251"
},
{
"name": "CVE-2023-53252",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53252"
},
{
"name": "CVE-2023-53255",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53255"
},
{
"name": "CVE-2023-53257",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53257"
},
{
"name": "CVE-2023-53258",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53258"
},
{
"name": "CVE-2023-53260",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53260"
},
{
"name": "CVE-2023-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53263"
},
{
"name": "CVE-2023-53264",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53264"
},
{
"name": "CVE-2023-53272",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53272"
},
{
"name": "CVE-2023-53274",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53274"
},
{
"name": "CVE-2023-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53275"
},
{
"name": "CVE-2023-53280",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53280"
},
{
"name": "CVE-2023-53282",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53282"
},
{
"name": "CVE-2023-53286",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53286"
},
{
"name": "CVE-2023-53287",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53287"
},
{
"name": "CVE-2023-53288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53288"
},
{
"name": "CVE-2023-53291",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53291"
},
{
"name": "CVE-2023-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53292"
},
{
"name": "CVE-2023-53303",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53303"
},
{
"name": "CVE-2023-53304",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53304"
},
{
"name": "CVE-2023-53309",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53309"
},
{
"name": "CVE-2023-53311",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53311"
},
{
"name": "CVE-2023-53312",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53312"
},
{
"name": "CVE-2023-53313",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53313"
},
{
"name": "CVE-2023-53314",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53314"
},
{
"name": "CVE-2023-53316",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53316"
},
{
"name": "CVE-2023-53319",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53319"
},
{
"name": "CVE-2023-53321",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53321"
},
{
"name": "CVE-2023-53322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53322"
},
{
"name": "CVE-2023-53323",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53323"
},
{
"name": "CVE-2023-53324",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53324"
},
{
"name": "CVE-2023-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53325"
},
{
"name": "CVE-2023-53328",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53328"
},
{
"name": "CVE-2023-53331",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53331"
},
{
"name": "CVE-2023-53333",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53333"
},
{
"name": "CVE-2023-53336",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53336"
},
{
"name": "CVE-2023-53338",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53338"
},
{
"name": "CVE-2023-53339",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53339"
},
{
"name": "CVE-2023-53342",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53342"
},
{
"name": "CVE-2023-53343",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53343"
},
{
"name": "CVE-2023-53350",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53350"
},
{
"name": "CVE-2023-53352",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53352"
},
{
"name": "CVE-2023-53354",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53354"
},
{
"name": "CVE-2023-53356",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53356"
},
{
"name": "CVE-2023-53357",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53357"
},
{
"name": "CVE-2023-53360",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53360"
},
{
"name": "CVE-2023-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53362"
},
{
"name": "CVE-2023-53364",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53364"
},
{
"name": "CVE-2023-53365",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53365"
},
{
"name": "CVE-2023-53367",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53367"
},
{
"name": "CVE-2023-53368",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53368"
},
{
"name": "CVE-2023-53369",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53369"
},
{
"name": "CVE-2023-53370",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53370"
},
{
"name": "CVE-2023-53371",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53371"
},
{
"name": "CVE-2023-53374",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53374"
},
{
"name": "CVE-2023-53377",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53377"
},
{
"name": "CVE-2023-53379",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53379"
},
{
"name": "CVE-2023-53380",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53380"
},
{
"name": "CVE-2023-53384",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53384"
},
{
"name": "CVE-2023-53385",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53385"
},
{
"name": "CVE-2023-53386",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53386"
},
{
"name": "CVE-2023-53391",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53391"
},
{
"name": "CVE-2023-53394",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53394"
},
{
"name": "CVE-2023-53395",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53395"
},
{
"name": "CVE-2023-53397",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53397"
},
{
"name": "CVE-2023-53401",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53401"
},
{
"name": "CVE-2023-53420",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53420"
},
{
"name": "CVE-2023-53421",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53421"
},
{
"name": "CVE-2023-53424",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53424"
},
{
"name": "CVE-2023-53425",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53425"
},
{
"name": "CVE-2023-53426",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53426"
},
{
"name": "CVE-2023-53428",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53428"
},
{
"name": "CVE-2023-53429",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53429"
},
{
"name": "CVE-2023-53432",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53432"
},
{
"name": "CVE-2023-53436",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53436"
},
{
"name": "CVE-2023-53438",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53438"
},
{
"name": "CVE-2023-53441",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53441"
},
{
"name": "CVE-2023-53442",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53442"
},
{
"name": "CVE-2023-53444",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53444"
},
{
"name": "CVE-2023-53446",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53446"
},
{
"name": "CVE-2023-53447",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53447"
},
{
"name": "CVE-2023-53448",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53448"
},
{
"name": "CVE-2023-53451",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53451"
},
{
"name": "CVE-2023-53454",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53454"
},
{
"name": "CVE-2023-53456",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53456"
},
{
"name": "CVE-2023-53457",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53457"
},
{
"name": "CVE-2023-53461",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53461"
},
{
"name": "CVE-2023-53462",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53462"
},
{
"name": "CVE-2023-53463",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53463"
},
{
"name": "CVE-2023-53465",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53465"
},
{
"name": "CVE-2023-53472",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53472"
},
{
"name": "CVE-2023-53479",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53479"
},
{
"name": "CVE-2023-53480",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53480"
},
{
"name": "CVE-2023-53485",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53485"
},
{
"name": "CVE-2023-53487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53487"
},
{
"name": "CVE-2023-53488",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53488"
},
{
"name": "CVE-2023-53490",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53490"
},
{
"name": "CVE-2023-53491",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53491"
},
{
"name": "CVE-2023-53492",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53492"
},
{
"name": "CVE-2023-53493",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53493"
},
{
"name": "CVE-2023-53495",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53495"
},
{
"name": "CVE-2023-53496",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53496"
},
{
"name": "CVE-2023-53500",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53500"
},
{
"name": "CVE-2023-53501",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53501"
},
{
"name": "CVE-2023-53504",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53504"
},
{
"name": "CVE-2023-53505",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53505"
},
{
"name": "CVE-2023-53507",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53507"
},
{
"name": "CVE-2023-53508",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53508"
},
{
"name": "CVE-2023-53510",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53510"
},
{
"name": "CVE-2023-53515",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53515"
},
{
"name": "CVE-2023-53516",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53516"
},
{
"name": "CVE-2023-53518",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53518"
},
{
"name": "CVE-2023-53519",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53519"
},
{
"name": "CVE-2023-53520",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53520"
},
{
"name": "CVE-2023-53523",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53523"
},
{
"name": "CVE-2023-53526",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53526"
},
{
"name": "CVE-2023-53527",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53527"
},
{
"name": "CVE-2023-53528",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53528"
},
{
"name": "CVE-2023-53530",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53530"
},
{
"name": "CVE-2023-53531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53531"
},
{
"name": "CVE-2025-38692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38692"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2025-39739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39739"
},
{
"name": "CVE-2025-39750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39750"
},
{
"name": "CVE-2025-39758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39758"
},
{
"name": "CVE-2025-39763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39763"
},
{
"name": "CVE-2025-39797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39797"
},
{
"name": "CVE-2025-39833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39833"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2025-39882",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39882"
},
{
"name": "CVE-2025-39889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39889"
},
{
"name": "CVE-2025-39925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39925"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-39938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39938"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2025-39946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39946"
},
{
"name": "CVE-2025-39947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39947"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-39957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39957"
},
{
"name": "CVE-2025-39965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39965"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-39981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39981"
},
{
"name": "CVE-2025-39982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39982"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2025-40005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40005"
},
{
"name": "CVE-2025-40016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40016"
},
{
"name": "CVE-2025-40018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40018"
},
{
"name": "CVE-2025-40019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40019"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-40102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40102"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2023-53538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53538"
},
{
"name": "CVE-2023-53539",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53539"
},
{
"name": "CVE-2023-53540",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53540"
},
{
"name": "CVE-2023-53541",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53541"
},
{
"name": "CVE-2023-53543",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53543"
},
{
"name": "CVE-2023-53545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53545"
},
{
"name": "CVE-2023-53546",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53546"
},
{
"name": "CVE-2023-53548",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53548"
},
{
"name": "CVE-2023-53550",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53550"
},
{
"name": "CVE-2023-53552",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53552"
},
{
"name": "CVE-2023-53553",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53553"
},
{
"name": "CVE-2023-53554",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53554"
},
{
"name": "CVE-2023-53555",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53555"
},
{
"name": "CVE-2023-53556",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53556"
},
{
"name": "CVE-2023-53557",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53557"
},
{
"name": "CVE-2023-53558",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53558"
},
{
"name": "CVE-2023-53559",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53559"
},
{
"name": "CVE-2023-53560",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53560"
},
{
"name": "CVE-2023-53563",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53563"
},
{
"name": "CVE-2023-53568",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53568"
},
{
"name": "CVE-2023-53570",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53570"
},
{
"name": "CVE-2023-53572",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53572"
},
{
"name": "CVE-2023-53574",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53574"
},
{
"name": "CVE-2023-53575",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53575"
},
{
"name": "CVE-2023-53577",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53577"
},
{
"name": "CVE-2023-53579",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53579"
},
{
"name": "CVE-2023-53580",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53580"
},
{
"name": "CVE-2023-53581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53581"
},
{
"name": "CVE-2023-53583",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53583"
},
{
"name": "CVE-2023-53585",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53585"
},
{
"name": "CVE-2023-53588",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53588"
},
{
"name": "CVE-2023-53593",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53593"
},
{
"name": "CVE-2023-53596",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53596"
},
{
"name": "CVE-2023-53597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53597"
},
{
"name": "CVE-2023-53599",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53599"
},
{
"name": "CVE-2023-53600",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53600"
},
{
"name": "CVE-2023-53601",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53601"
},
{
"name": "CVE-2023-53602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53602"
},
{
"name": "CVE-2023-53603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53603"
},
{
"name": "CVE-2023-53611",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53611"
},
{
"name": "CVE-2023-53613",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53613"
},
{
"name": "CVE-2023-53615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53615"
},
{
"name": "CVE-2023-53616",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53616"
},
{
"name": "CVE-2023-53617",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53617"
},
{
"name": "CVE-2023-53618",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53618"
},
{
"name": "CVE-2023-53619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53619"
},
{
"name": "CVE-2023-53621",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53621"
},
{
"name": "CVE-2023-53622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53622"
},
{
"name": "CVE-2023-53631",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53631"
},
{
"name": "CVE-2023-53632",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53632"
},
{
"name": "CVE-2023-53633",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53633"
},
{
"name": "CVE-2023-53638",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53638"
},
{
"name": "CVE-2023-53645",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53645"
},
{
"name": "CVE-2023-53646",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53646"
},
{
"name": "CVE-2023-53647",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53647"
},
{
"name": "CVE-2023-53648",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53648"
},
{
"name": "CVE-2023-53649",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53649"
},
{
"name": "CVE-2023-53650",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53650"
},
{
"name": "CVE-2023-53652",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53652"
},
{
"name": "CVE-2023-53653",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53653"
},
{
"name": "CVE-2023-53637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53637"
},
{
"name": "CVE-2024-45016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45016"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2023-53654",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53654"
},
{
"name": "CVE-2023-53656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53656"
},
{
"name": "CVE-2023-53657",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53657"
},
{
"name": "CVE-2023-53658",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53658"
},
{
"name": "CVE-2023-53659",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53659"
},
{
"name": "CVE-2023-53660",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53660"
},
{
"name": "CVE-2023-53662",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53662"
},
{
"name": "CVE-2023-53663",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53663"
},
{
"name": "CVE-2023-53665",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53665"
},
{
"name": "CVE-2023-53666",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53666"
},
{
"name": "CVE-2023-53668",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53668"
},
{
"name": "CVE-2023-53670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53670"
},
{
"name": "CVE-2023-53672",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53672"
},
{
"name": "CVE-2023-53673",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53673"
},
{
"name": "CVE-2023-53674",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53674"
},
{
"name": "CVE-2023-53681",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53681"
},
{
"name": "CVE-2023-53686",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53686"
},
{
"name": "CVE-2023-53687",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53687"
},
{
"name": "CVE-2023-53693",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53693"
},
{
"name": "CVE-2023-53697",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53697"
},
{
"name": "CVE-2023-53698",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53698"
},
{
"name": "CVE-2023-53699",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53699"
},
{
"name": "CVE-2023-53703",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53703"
},
{
"name": "CVE-2023-53704",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53704"
},
{
"name": "CVE-2023-53707",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53707"
},
{
"name": "CVE-2023-53708",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53708"
},
{
"name": "CVE-2023-53711",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53711"
},
{
"name": "CVE-2023-53713",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53713"
},
{
"name": "CVE-2023-53718",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53718"
},
{
"name": "CVE-2023-53721",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53721"
},
{
"name": "CVE-2023-53722",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53722"
},
{
"name": "CVE-2023-53725",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53725"
},
{
"name": "CVE-2023-53726",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53726"
},
{
"name": "CVE-2023-53727",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53727"
},
{
"name": "CVE-2023-53728",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53728"
},
{
"name": "CVE-2023-53729",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53729"
},
{
"name": "CVE-2023-53730",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53730"
},
{
"name": "CVE-2023-53731",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53731"
},
{
"name": "CVE-2023-53733",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53733"
},
{
"name": "CVE-2025-39895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39895"
},
{
"name": "CVE-2025-39900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39900"
},
{
"name": "CVE-2025-39948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39948"
},
{
"name": "CVE-2025-39952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39952"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2025-39984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39984"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-39991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39991"
},
{
"name": "CVE-2025-39993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39993"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-39997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39997"
},
{
"name": "CVE-2025-40000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40000"
},
{
"name": "CVE-2025-40010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40010"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2025-40012",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40012"
},
{
"name": "CVE-2025-40013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40013"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-40082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40082"
},
{
"name": "CVE-2025-40091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40091"
},
{
"name": "CVE-2022-50334",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50334"
},
{
"name": "CVE-2022-50470",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50470"
},
{
"name": "CVE-2022-50471",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50471"
},
{
"name": "CVE-2022-50472",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50472"
},
{
"name": "CVE-2022-50475",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50475"
},
{
"name": "CVE-2022-50478",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50478"
},
{
"name": "CVE-2022-50479",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50479"
},
{
"name": "CVE-2022-50480",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50480"
},
{
"name": "CVE-2022-50482",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50482"
},
{
"name": "CVE-2022-50484",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50484"
},
{
"name": "CVE-2022-50485",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50485"
},
{
"name": "CVE-2022-50487",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50487"
},
{
"name": "CVE-2022-50488",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50488"
},
{
"name": "CVE-2022-50489",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50489"
},
{
"name": "CVE-2022-50490",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50490"
},
{
"name": "CVE-2022-50492",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50492"
},
{
"name": "CVE-2022-50493",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50493"
},
{
"name": "CVE-2022-50494",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50494"
},
{
"name": "CVE-2022-50496",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50496"
},
{
"name": "CVE-2022-50497",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50497"
},
{
"name": "CVE-2022-50498",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50498"
},
{
"name": "CVE-2022-50499",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50499"
},
{
"name": "CVE-2022-50501",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50501"
},
{
"name": "CVE-2022-50503",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50503"
},
{
"name": "CVE-2022-50504",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50504"
},
{
"name": "CVE-2022-50505",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50505"
},
{
"name": "CVE-2022-50509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50509"
},
{
"name": "CVE-2022-50511",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50511"
},
{
"name": "CVE-2022-50512",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50512"
},
{
"name": "CVE-2022-50513",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50513"
},
{
"name": "CVE-2022-50514",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50514"
},
{
"name": "CVE-2022-50515",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50515"
},
{
"name": "CVE-2022-50516",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50516"
},
{
"name": "CVE-2022-50519",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50519"
},
{
"name": "CVE-2022-50520",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50520"
},
{
"name": "CVE-2022-50521",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50521"
},
{
"name": "CVE-2022-50523",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50523"
},
{
"name": "CVE-2022-50524",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50524"
},
{
"name": "CVE-2022-50525",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50525"
},
{
"name": "CVE-2022-50526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50526"
},
{
"name": "CVE-2022-50527",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50527"
},
{
"name": "CVE-2022-50528",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50528"
},
{
"name": "CVE-2022-50529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50529"
},
{
"name": "CVE-2022-50530",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50530"
},
{
"name": "CVE-2022-50532",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50532"
},
{
"name": "CVE-2022-50534",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50534"
},
{
"name": "CVE-2022-50535",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50535"
},
{
"name": "CVE-2022-50537",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50537"
},
{
"name": "CVE-2022-50541",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50541"
},
{
"name": "CVE-2022-50542",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50542"
},
{
"name": "CVE-2022-50543",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50543"
},
{
"name": "CVE-2022-50544",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50544"
},
{
"name": "CVE-2022-50545",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50545"
},
{
"name": "CVE-2022-50546",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50546"
},
{
"name": "CVE-2022-50549",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50549"
},
{
"name": "CVE-2022-50551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50551"
},
{
"name": "CVE-2022-50553",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50553"
},
{
"name": "CVE-2022-50556",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50556"
},
{
"name": "CVE-2022-50559",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50559"
},
{
"name": "CVE-2022-50560",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50560"
},
{
"name": "CVE-2022-50561",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50561"
},
{
"name": "CVE-2022-50562",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50562"
},
{
"name": "CVE-2022-50563",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50563"
},
{
"name": "CVE-2022-50564",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50564"
},
{
"name": "CVE-2022-50566",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50566"
},
{
"name": "CVE-2022-50567",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50567"
},
{
"name": "CVE-2022-50568",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50568"
},
{
"name": "CVE-2022-50570",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50570"
},
{
"name": "CVE-2022-50572",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50572"
},
{
"name": "CVE-2022-50574",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50574"
},
{
"name": "CVE-2022-50575",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50575"
},
{
"name": "CVE-2022-50576",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50576"
},
{
"name": "CVE-2022-50577",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50577"
},
{
"name": "CVE-2022-50578",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50578"
},
{
"name": "CVE-2022-50579",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50579"
},
{
"name": "CVE-2022-50580",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50580"
},
{
"name": "CVE-2022-50581",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50581"
},
{
"name": "CVE-2022-50582",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50582"
},
{
"name": "CVE-2023-53533",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53533"
},
{
"name": "CVE-2023-53534",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53534"
},
{
"name": "CVE-2023-53542",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53542"
},
{
"name": "CVE-2023-53547",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53547"
},
{
"name": "CVE-2023-53551",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53551"
},
{
"name": "CVE-2023-53562",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53562"
},
{
"name": "CVE-2023-53564",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53564"
},
{
"name": "CVE-2023-53566",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53566"
},
{
"name": "CVE-2023-53567",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53567"
},
{
"name": "CVE-2023-53571",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53571"
},
{
"name": "CVE-2023-53576",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53576"
},
{
"name": "CVE-2023-53578",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53578"
},
{
"name": "CVE-2023-53582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53582"
},
{
"name": "CVE-2023-53587",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53587"
},
{
"name": "CVE-2023-53589",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53589"
},
{
"name": "CVE-2023-53591",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53591"
},
{
"name": "CVE-2023-53592",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53592"
},
{
"name": "CVE-2023-53594",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53594"
},
{
"name": "CVE-2023-53598",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53598"
},
{
"name": "CVE-2023-53604",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53604"
},
{
"name": "CVE-2023-53605",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53605"
},
{
"name": "CVE-2023-53607",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53607"
},
{
"name": "CVE-2023-53608",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53608"
},
{
"name": "CVE-2023-53612",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53612"
},
{
"name": "CVE-2023-53625",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53625"
},
{
"name": "CVE-2023-53626",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53626"
},
{
"name": "CVE-2023-53639",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53639"
},
{
"name": "CVE-2023-53640",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53640"
},
{
"name": "CVE-2023-53641",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53641"
},
{
"name": "CVE-2023-53644",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53644"
},
{
"name": "CVE-2023-53651",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53651"
},
{
"name": "CVE-2023-53667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53667"
},
{
"name": "CVE-2023-53675",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53675"
},
{
"name": "CVE-2023-53679",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53679"
},
{
"name": "CVE-2023-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53680"
},
{
"name": "CVE-2023-53683",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53683"
},
{
"name": "CVE-2023-53692",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53692"
},
{
"name": "CVE-2023-53695",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53695"
},
{
"name": "CVE-2023-53696",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53696"
},
{
"name": "CVE-2023-53700",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53700"
},
{
"name": "CVE-2023-53705",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53705"
},
{
"name": "CVE-2023-53709",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53709"
},
{
"name": "CVE-2023-53715",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53715"
},
{
"name": "CVE-2023-53716",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53716"
},
{
"name": "CVE-2023-53717",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53717"
},
{
"name": "CVE-2023-53719",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53719"
},
{
"name": "CVE-2023-53723",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53723"
},
{
"name": "CVE-2023-53724",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53724"
},
{
"name": "CVE-2023-7324",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7324"
},
{
"name": "CVE-2022-48956",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48956"
},
{
"name": "CVE-2022-49014",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49014"
},
{
"name": "CVE-2024-47674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47674"
},
{
"name": "CVE-2024-47684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47684"
},
{
"name": "CVE-2024-47706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47706"
},
{
"name": "CVE-2024-49860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49860"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-50115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50115"
},
{
"name": "CVE-2024-50125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50125"
},
{
"name": "CVE-2024-50154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50154"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2024-8805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8805"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2023-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52923"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2024-56664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56664"
},
{
"name": "CVE-2024-57893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57893"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2022-49080",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49080"
},
{
"name": "CVE-2022-49179",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49179"
},
{
"name": "CVE-2022-49545",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49545"
},
{
"name": "CVE-2022-49563",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49563"
},
{
"name": "CVE-2022-49564",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49564"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2022-49053",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49053"
},
{
"name": "CVE-2022-49465",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49465"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
},
{
"name": "CVE-2025-21971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21971"
},
{
"name": "CVE-2025-37752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37752"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-38083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38083"
},
{
"name": "CVE-2025-38177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38177"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38476"
},
{
"name": "CVE-2025-38477",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38477"
},
{
"name": "CVE-2025-38494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38494"
},
{
"name": "CVE-2025-38495",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38495"
},
{
"name": "CVE-2025-38498",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38498"
},
{
"name": "CVE-2025-38499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38499"
},
{
"name": "CVE-2025-38008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38008"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38618"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
}
],
"initial_release_date": "2025-11-21T00:00:00",
"last_revision_date": "2025-11-21T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-1032",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-11-21T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux de SUSE. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux de SUSE",
"vendor_advisories": [
{
"published_at": "2025-11-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4128-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254128-1"
},
{
"published_at": "2025-11-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4123-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254123-1"
},
{
"published_at": "2025-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4140-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254140-1"
},
{
"published_at": "2025-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4141-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254141-1"
},
{
"published_at": "2025-11-19",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4139-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254139-1"
},
{
"published_at": "2025-11-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4135-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254135-1"
},
{
"published_at": "2025-11-15",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4111-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254111-1"
},
{
"published_at": "2025-11-20",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4149-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254149-1"
},
{
"published_at": "2025-11-18",
"title": "Bulletin de s\u00e9curit\u00e9 SUSE SUSE-SU-2025:4132-1",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-20254132-1"
}
]
}
厂商已发布了漏洞修复程序,请及时关注更新: https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c
| Name | Linux Kernel |
|---|
{
"cves": {
"cve": {
"cveNumber": "CVE-2024-50279",
"cveUrl": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
}
},
"description": "Linux kernel\u662f\u7f8e\u56fdLinux\u57fa\u91d1\u4f1a\u7684\u5f00\u6e90\u64cd\u4f5c\u7cfb\u7edfLinux\u6240\u4f7f\u7528\u7684\u5185\u6838\u3002\n\nLinux kernel\u5b58\u5728\u5b89\u5168\u6f0f\u6d1e\uff0c\u8be5\u6f0f\u6d1e\u6e90\u4e8e\u5141\u8bb8\u8d8a\u754c\u8bbf\u95ee\u5185\u5b58\u3002\u76ee\u524d\u6ca1\u6709\u8be6\u7ec6\u7684\u6f0f\u6d1e\u7ec6\u8282\u63d0\u4f9b\u3002",
"formalWay": "\u5382\u5546\u5df2\u53d1\u5e03\u4e86\u6f0f\u6d1e\u4fee\u590d\u7a0b\u5e8f\uff0c\u8bf7\u53ca\u65f6\u5173\u6ce8\u66f4\u65b0\uff1a\r\nhttps://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c",
"isEvent": "\u901a\u7528\u8f6f\u786c\u4ef6\u6f0f\u6d1e",
"number": "CNVD-2024-46392",
"openTime": "2024-11-28",
"patchDescription": "Linux kernel\u662f\u7f8e\u56fdLinux\u57fa\u91d1\u4f1a\u7684\u5f00\u6e90\u64cd\u4f5c\u7cfb\u7edfLinux\u6240\u4f7f\u7528\u7684\u5185\u6838\u3002\r\n\r\nLinux kernel\u5b58\u5728\u5b89\u5168\u6f0f\u6d1e\uff0c\u8be5\u6f0f\u6d1e\u6e90\u4e8e\u5141\u8bb8\u8d8a\u754c\u8bbf\u95ee\u5185\u5b58\u3002\u76ee\u524d\u6ca1\u6709\u8be6\u7ec6\u7684\u6f0f\u6d1e\u7ec6\u8282\u63d0\u4f9b\u3002\u76ee\u524d\uff0c\u4f9b\u5e94\u5546\u53d1\u5e03\u4e86\u5b89\u5168\u516c\u544a\u53ca\u76f8\u5173\u8865\u4e01\u4fe1\u606f\uff0c\u4fee\u590d\u4e86\u6b64\u6f0f\u6d1e\u3002",
"patchName": "Linux kernel\u5b58\u5728\u672a\u660e\u6f0f\u6d1e\uff08CNVD-2024-46392\uff09\u7684\u8865\u4e01",
"products": {
"product": "Linux Kernel"
},
"referenceLink": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279",
"serverity": "\u4e2d",
"submitTime": "2024-11-21",
"title": "Linux kernel\u5b58\u5728\u672a\u660e\u6f0f\u6d1e\uff08CNVD-2024-46392\uff09"
}
FKIE_CVE-2024-50279
Vulnerability from fkie_nvd - Published: 2024-11-19 02:16 - Updated: 2026-06-17 08:047.1 (High) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.12 | |
| linux | linux_kernel | 6.12 | |
| linux | linux_kernel | 6.12 | |
| linux | linux_kernel | 6.12 | |
| linux | linux_kernel | 6.12 | |
| linux | linux_kernel | 6.12 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4fa4feb873cea0e9d6ff883b37cca6f33169d8b4",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "8501e38dc9e0060814c4085815fc83da3e6d43bf",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ee1f74925717ab36f6a091104c170639501ce818",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "56507203e1b6127967ec2b51fb0b23a0d4af1334",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "e57648ce325fa405fe6bbd0e6a618ced7c301a2d",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "3b02c40ff10fdf83cc545850db208de855ebe22c",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
},
{
"lessThan": "792227719725497ce10a8039803bec13f89f8910",
"status": "affected",
"version": "f494a9c6b1b6dd9a9f21bbb75d9210d478eeb498",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-cache-target.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.13"
},
{
"lessThan": "3.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.324",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.286",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.230",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.172",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.117",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.61",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.12",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6F34367D-A869-4C97-A01F-F5209F24FC10",
"versionEndExcluding": "4.19.324",
"versionStartIncluding": "3.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "9952C897-8A61-4D4B-9D6D-7D063E9EA15E",
"versionEndExcluding": "5.4.286",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BF5B32D0-72C9-41C3-A0BB-D4946153C134",
"versionEndExcluding": "5.10.230",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "88812664-4296-42AC-AE0F-ED71086C1BB1",
"versionEndExcluding": "5.15.172",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0DD7F755-2F6B-4707-8973-78496AD5AA8E",
"versionEndExcluding": "6.1.117",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "630ED7EB-C97E-4435-B884-1E309E40D6F3",
"versionEndExcluding": "6.6.61",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0BD000F7-3DAD-4DD3-8906-98EA1EC67E95",
"versionEndExcluding": "6.11.8",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*",
"matchCriteriaId": "7F361E1D-580F-4A2D-A509-7615F73167A1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*",
"matchCriteriaId": "925478D0-3E3D-4E6F-ACD5-09F28D5DF82C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*",
"matchCriteriaId": "3C95E234-D335-4B6C-96BF-E2CEBD8654ED",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*",
"matchCriteriaId": "E0F717D8-3014-4F84-8086-0124B2111379",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc5:*:*:*:*:*:*",
"matchCriteriaId": "24DBE6C7-2AAE-4818-AED2-E131F153D2FA",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc6:*:*:*:*:*:*",
"matchCriteriaId": "24B88717-53F5-42AA-9B72-14C707639E3F",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"\ndmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\"\ndmsetup create corig --table \"0 524288 linear /dev/sdc 262144\"\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\"\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u003effffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm cache: corrige el acceso fuera de los l\u00edmites al conjunto de bits sucio al cambiar el tama\u00f1o dm-cache verifica los bits sucios de los bloques de cach\u00e9 que se deben descartar al reducir el dispositivo r\u00e1pido, pero un error de \u00edndice en la iteraci\u00f3n del conjunto de bits provoca un acceso fuera de los l\u00edmites. Reproducir los pasos: 1. crear un dispositivo de cach\u00e9 de 1024 bloques de cach\u00e9 (128 bytes de bitset sucio) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. reducir el dispositivo r\u00e1pido a 512 bloques de cach\u00e9, lo que activa el acceso fuera de los l\u00edmites al bitset sucio. bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN informa: ERROR: KASAN: vmalloc-out-of-bounds en cache_preresume+0x269/0x7b0 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffffc900000f3080 por la tarea dmsetup/131 (...snip...) La direcci\u00f3n con errores pertenece al mapeo virtual en [ffffc900000f3000, ffffc900000f5000) creado por: cache_ctr+0x176a/0x35f0 (...snip...) Estado de la memoria alrededor de la direcci\u00f3n con errores: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 ..."
}
],
"id": "CVE-2024-50279",
"lastModified": "2026-06-17T08:04:05.377",
"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": "nvd@nist.gov",
"type": "Primary"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-50279",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:14:43.545051Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-11-19T02:16:30.210",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-V6RG-QV6J-P6GP
Vulnerability from github – Published: 2024-11-19 03:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix out-of-bounds access to the dirty bitset when resizing
dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.
Reproduce steps:
- create a cache device of 1024 cache blocks (128 bytes dirty bitset)
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
- shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)
dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131
(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0
(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by making the index post-incremented.
{
"affected": [],
"aliases": [
"CVE-2024-50279"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:30Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"\ndmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\"\ndmsetup create corig --table \"0 524288 linear /dev/sdc 262144\"\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\"\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u003effffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented.",
"id": "GHSA-v6rg-qv6j-p6gp",
"modified": "2025-11-04T00:32:03Z",
"published": "2024-11-19T03:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"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"
}
]
}
ICSA-25-226-07
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00MSRC_CVE-2024-50279
Vulnerability from csaf_microsoft - Published: 2024-11-02 00:00 - Updated: 2026-02-19 01:15OESA-2024-2537 (CVE-2024-40927)
Vulnerability from osv_openeuler – Published: 2024-12-13 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhci_dbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn't really hint at there being a problem at all). It took me months of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn't have been left in at all). > Another fix to solve clearing the caches of all stream rings with > cancelled TDs is needed, but not as urgent. 3 years after that statement and 14 years after the original bug was introduced, I think it's finally time to fix it. And maybe next time let's not leave bugs unfixed (that are actually worse than the original bug), and let's actually get people to review kernel commits please. Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use hdparm to mark an early sector (e.g. 1024) on a disk as bad, then cat /dev/sdX > /dev/null in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn't get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the cat in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro'd and tested on an Apple M1 Mac Mini (dwc3 host). On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---(CVE-2024-40927)
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.(CVE-2024-47697)
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.(CVE-2024-47713)
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024(CVE-2024-47738)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.(CVE-2024-49897)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] "dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49923)
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") allows the "port_transmit_rate_kbps" to be set to a value of 0, which is then passed to the "div_s64" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.(CVE-2024-49977)
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.(CVE-2024-49997)
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.(CVE-2024-50103)
In the Linux kernel, the following vulnerability has been resolved: x86/lam: Disable ADDRESS_MASKING in most cases Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in market that support LAM yet, so currently nobody is affected by this issue. [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.(CVE-2024-50116)
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)(CVE-2024-50117)
In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.(CVE-2024-50134)
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup() Clang static checker(scan-build) throws below warning: | drivers/firmware/arm_scmi/driver.c:line 2915, column 2 | Attempt to free released memory. When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup() will run twice which causes double free of 'dbg->name'. Remove the redundant scmi_debugfs_common_cleanup() to fix this problem.(CVE-2024-50159)
(CVE-2024-50194)
In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series "maple_tree: correct tree corruption on spanning store", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 ("mm/mmap: avoid zeroing vma tree in mmap_region()"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \ pivot = 0xffff / \ pivot = ULONG_MAX / ---truncated---(CVE-2024-50200)
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 release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that. pabeni@redhat.com: fixed commit message typo
In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334(CVE-2024-50224)
In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.(CVE-2024-50239)
In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. rjw: Changelog edits
In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: <TASK> get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0 cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template kfree(t) //removed from templ_list getinfo() t = xt_find_table_lock list_for_each_entry(tmpl, &xt_templates[af]...) if (strcmp(tmpl->name, name)) continue; //table not found try_module_get list_for_each_entry(t, &xt_net->tables[af]...) return t; //not get refcnt module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.(CVE-2024-50257)
In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 ("mm: khugepaged: make khugepaged_enter() void function") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.(CVE-2024-50263)
In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue.(CVE-2024-50267)
In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The "*cmd" variable can be controlled by the user via debugfs. That means "new_cam" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()(CVE-2024-50268)
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.(CVE-2024-50279)
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)
In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.(CVE-2024-50290)
In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.(CVE-2024-50292)
In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ jarkko: tweaked the commit message a bit to have an appropriate closes tag.
In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)
In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20(CVE-2024-53068)
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.(CVE-2024-53072)
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.(CVE-2024-53082)
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.(CVE-2024-53104)
In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.(CVE-2024-53110)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.(CVE-2024-53112)
In the Linux kernel, the following vulnerability has been resolved: bpf: sync_linked_regs() must preserve subreg_def Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5).(CVE-2024-53125)
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.(CVE-2024-53130)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-source-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"perf-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"python3-perf-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-64.0.0.61.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-source-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"perf-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"python3-perf-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-64.0.0.61.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-64.0.0.61.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N\u0026gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/\u0026quot;should never happen\u0026quot; paths to ensure we at least clear any affected TDs, even if we can\u0026apos;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 (\u0026quot;USB: xhci: Correct assumptions about number of rings per endpoint.\u0026quot;) early on in the XHCI driver\u0026apos;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (\u0026quot;xhci: split handling halted endpoints into two steps\u0026quot;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 (\u0026quot;xhci: Fix failure to give back some cached cancelled URBs.\u0026quot;), it was acknowledged again. [Mathias: commit 94f339147fc3 (\u0026quot;xhci: Fix failure to give back some cached cancelled URBs.\u0026quot;) was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhci_dbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn\u0026apos;t really hint at there being a problem at all). It took me *months* of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn\u0026apos;t have been left in at all). \u0026gt; Another fix to solve clearing the caches of all stream rings with \u0026gt; cancelled TDs is needed, but not as urgent. 3 years after that statement and 14 years after the original bug was introduced, I think it\u0026apos;s finally time to fix it. And maybe next time let\u0026apos;s not leave bugs unfixed (that are actually worse than the original bug), and let\u0026apos;s actually get people to review kernel commits please. Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use `hdparm` to mark an early sector (e.g. 1024) on a disk as bad, then `cat /dev/sdX \u0026gt; /dev/null` in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn\u0026apos;t get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the `cat` in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro\u0026apos;d and tested on an Apple M1 Mac Mini (dwc3 host). On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---(CVE-2024-40927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.(CVE-2024-47697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since \u0026apos;__dev_queue_xmit()\u0026apos; should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(\u0026amp;local-\u0026gt;queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(\u0026amp;local-\u0026gt;queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in \u0026apos;ieee80211_do_stop()\u0026apos;, where actual work is performed outside of a section with interrupts disabled.(CVE-2024-47713)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don\u0026apos;t use rate mask for offchannel TX either Like the commit ab9177d83c04 (\u0026quot;wifi: mac80211: don\u0026apos;t use rate mask for scanning\u0026quot;), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\u0026quot;cfg80211: fix default HE tx bitrate mask in 2G band\u0026quot;), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024(CVE-2024-47738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.(CVE-2024-49897)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT \u0026amp; HOW] \u0026quot;dcn20_validate_apply_pipe_split_flags\u0026quot; dereferences merge, and thus it cannot be a null pointer. Let\u0026apos;s pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49923)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\u0026quot;net: stmmac: No need to calculate speed divider when offload is disabled\u0026quot;) allows the \u0026quot;port_transmit_rate_kbps\u0026quot; to be set to a value of 0, which is then passed to the \u0026quot;div_s64\u0026quot; function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.(CVE-2024-49977)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.(CVE-2024-49997)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.(CVE-2024-50103)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: x86/lam: Disable ADDRESS_MASKING in most cases Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in market that support LAM yet, so currently nobody is affected by this issue. [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ [ dhansen: update SPECULATION_MITIGATIONS -\u0026gt; CPU_MITIGATIONS ](CVE-2024-50112)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2\u0026apos;s own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.(CVE-2024-50116)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)(CVE-2024-50117)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \u0026quot;memcpy: detected field-spanning write error\u0026quot; warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field \u0026quot;p-\u0026gt;data\u0026quot; at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.(CVE-2024-50134)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup() Clang static checker(scan-build) throws below warning\uff1a | drivers/firmware/arm_scmi/driver.c:line 2915, column 2 | Attempt to free released memory. When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup() will run twice which causes double free of \u0026apos;dbg-\u0026gt;name\u0026apos;. Remove the redundant scmi_debugfs_common_cleanup() to fix this problem.(CVE-2024-50159)\r\n\r\n(CVE-2024-50194)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \u0026quot;maple_tree: correct tree corruption on spanning store\u0026quot;, v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\u0026quot;mm/mmap: avoid zeroing vma tree in mmap_region()\u0026quot;), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a \u0026apos;spanning store\u0026apos; and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas-\u0026gt;store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a \u0026apos;big node\u0026apos;, which is a special node which contains enough slots to contain two leaf node\u0026apos;s worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset \u0026lt;= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---(CVE-2024-50200)\r\n\r\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\u0026apos;s fd, and get the clk-\u0026gt;rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid\u0026apos;s fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the \u0026quot;ts\u0026quot; is not changed after that. [pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334(CVE-2024-50224)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\u0026quot;phy: qcom-qmp-usb: clean up probe initialisation\u0026quot;) removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.(CVE-2024-50239)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (\u0026amp;cpc_ptr-\u0026gt;rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (\u0026amp;rq-\u0026gt;__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (\u0026amp;sg_policy-\u0026gt;update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ](CVE-2024-50249)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: \u0026lt;TASK\u0026gt; get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0 cpu1 module_exit //mod-\u0026gt;state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template kfree(t) //removed from templ_list getinfo() t = xt_find_table_lock list_for_each_entry(tmpl, \u0026amp;xt_templates[af]...) if (strcmp(tmpl-\u0026gt;name, name)) continue; //table not found try_module_get list_for_each_entry(t, \u0026amp;xt_net-\u0026gt;tables[af]...) return t; //not get refcnt module_put(t-\u0026gt;me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table-\u0026gt;me. Check module in xt_net-\u0026gt;tables list re-traversal to fix it.(CVE-2024-50257)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\u0026quot;fork: use __mt_dup() to duplicate maple tree in dup_mmap()\u0026quot;) makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it\u0026apos;d require a very small allocation to fail (in practice \u0026apos;too small to fail\u0026apos;) that\u0026apos;d only occur in the most dire circumstances, meaning the fork would fail or be OOM\u0026apos;d in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn\u0026apos;t really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\u0026quot;mm: khugepaged: make khugepaged_enter() void function\u0026quot;) and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.(CVE-2024-50263)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \u0026quot;dev_dbg(\u0026amp;urb-\u0026gt;dev-\u0026gt;dev, ...\u0026quot; which happens after usb_free_urb(urb) is a use after free of the \u0026quot;urb\u0026quot; pointer. Store the \u0026quot;dev\u0026quot; pointer at the start of the function to avoid this issue.(CVE-2024-50267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \u0026quot;*cmd\u0026quot; variable can be controlled by the user via debugfs. That means \u0026quot;new_cam\u0026quot; can be as high as 255 while the size of the uc-\u0026gt;updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -\u0026gt; ucsi_send_command() -\u0026gt; ucsi_send_command_common() -\u0026gt; ucsi_run_command() // calls ucsi-\u0026gt;ops-\u0026gt;sync_control() -\u0026gt; ucsi_ccg_sync_control()(CVE-2024-50268)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot; dmsetup create cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot; dmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot; 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot; dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.(CVE-2024-50279)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.(CVE-2024-50290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.(CVE-2024-50292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern \u0026apos;0xxxxxxxe6\u0026apos;. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node-\u0026gt;back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------\u0026gt;+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.](CVE-2024-50301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let\u0026apos;s zero-initialize it during allocation to make sure that it can\u0026apos;t be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it\u0026apos;s valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev-\u0026gt;name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev-\u0026gt;name in scmi_bus_notifier(). So move the release of scmi_dev-\u0026gt;name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20(CVE-2024-53068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.(CVE-2024-53072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.(CVE-2024-53082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.(CVE-2024-53104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.(CVE-2024-53110)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: \u0026lt;TASK\u0026gt; ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... \u0026lt;/TASK\u0026gt; When \u0026apos;ioctl(OCFS2_IOC_GROUP_ADD, ...)\u0026apos; has failed for the particular inode in \u0026apos;ocfs2_verify_group_and_input()\u0026apos;, corresponding buffer head remains cached and subsequent call to the same \u0026apos;ioctl()\u0026apos; for the same inode issues the BUG() in \u0026apos;ocfs2_set_new_buffer_uptodate()\u0026apos; (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with \u0026apos;ocfs2_remove_from_cache()\u0026apos; on error path in \u0026apos;ocfs2_group_add()\u0026apos;.(CVE-2024-53112)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: bpf: sync_linked_regs() must preserve subreg_def Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set: 0: call bpf_ktime_get_ns call bpf_ktime_get_ns 1: r0 \u0026amp;= 0x7fffffff after verifier r0 \u0026amp;= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 \u0026lt; 10 goto +0 --------------\u0026gt; r11 = 0x2f5674a6 (r) 4: r1 \u0026gt;\u0026gt;= 32 r11 \u0026lt;\u0026lt;= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 \u0026lt; 0xa goto pc+0 r1 \u0026gt;\u0026gt;= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2) for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5).(CVE-2024-53125)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \u0026quot;block:block_dirty_buffer\u0026quot; tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \u0026quot;uptodate\u0026quot; state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh-\u0026gt;b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer\u0026apos;s uptodate flag.(CVE-2024-53130)",
"id": "OESA-2024-2537",
"modified": "2026-08-06T11:08:01Z",
"published": "2024-12-13T11:08:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2537"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47697"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47738"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49897"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49977"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49997"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50112"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50116"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50117"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50134"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50200"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50224"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50239"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50249"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50257"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50263"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50287"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50290"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50292"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50301"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50302"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53057"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53104"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53110"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53112"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53125"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53130"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-40927",
"CVE-2024-47697",
"CVE-2024-47713",
"CVE-2024-47738",
"CVE-2024-49897",
"CVE-2024-49923",
"CVE-2024-49977",
"CVE-2024-49991",
"CVE-2024-49997",
"CVE-2024-50103",
"CVE-2024-50112",
"CVE-2024-50116",
"CVE-2024-50117",
"CVE-2024-50134",
"CVE-2024-50159",
"CVE-2024-50194",
"CVE-2024-50200",
"CVE-2024-50210",
"CVE-2024-50224",
"CVE-2024-50239",
"CVE-2024-50249",
"CVE-2024-50257",
"CVE-2024-50263",
"CVE-2024-50267",
"CVE-2024-50268",
"CVE-2024-50279",
"CVE-2024-50287",
"CVE-2024-50290",
"CVE-2024-50292",
"CVE-2024-50301",
"CVE-2024-50302",
"CVE-2024-53057",
"CVE-2024-53068",
"CVE-2024-53072",
"CVE-2024-53082",
"CVE-2024-53104",
"CVE-2024-53110",
"CVE-2024-53112",
"CVE-2024-53125",
"CVE-2024-53130"
]
}
OESA-2025-1080 (CVE-2024-24858)
Vulnerability from osv_openeuler – Published: 2025-01-24 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.
(CVE-2024-24858)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: Create persistent IRQ handlers
The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference.
Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex.
In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate.
For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index.(CVE-2024-26813)
In the Linux kernel, the following vulnerability has been resolved:
geneve: make sure to pull inner header in geneve_rx()
syzbot triggered a bug in geneve_rx() [1]
Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
[1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch.
The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such.
This patch (of 2):
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted.
There are two flaws involved in this issue.
The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently.
The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing.
This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26966)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26969)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.
This results in a KFENCE bug notice.
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.(CVE-2024-26974)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix OOB in nilfs_set_de_type
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT".
static void nilfs_set_de_type(struct nilfs_dir_entry de, struct inode inode) { umode_t mode = inode->i_mode;
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}
However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.(CVE-2024-26981)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled.
As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
[function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.(CVE-2024-26996)
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...
Similar issue also found by Syzkaller:(CVE-2024-27001)
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Prevent release of buffer in I/O
When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.
Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.(CVE-2024-44969)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix out-of-bounds access to the dirty bitset when resizing
dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.
Reproduce steps:
- create a cache device of 1024 cache blocks (128 bytes dirty bitset)
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
- shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)
dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131
(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0
(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by making the index post-incremented.(CVE-2024-50279)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hdcp: Add encoder check in hdcp2_get_capability
Add encoder check in intel_hdcp2_get_capability to avoid null pointer error.(CVE-2024-53050)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()
ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument. The driver needs to check whether it is a NULL pointer before dereferencing it.(CVE-2024-53226)
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: Fix NULL pointer dereference in object->file
At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue:
[write fd] [umount]
cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...)
Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished.(CVE-2024-56549)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write
An offset from client could be a negative value, It could allows to write data outside the bounds of the allocated buffer. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf..(CVE-2024-56626)
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid potential out-of-bound access in fill_frame_info()
syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one.
Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case.
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY
Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.(CVE-2024-56690)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c
Add error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56728)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: check folio mapping after unlock in relocate_one_folio()
When we call btrfs_read_folio() to bring a folio uptodate, we unlock the folio. The result of that is that a different thread can modify the mapping (like remove it with invalidate) before we call folio_lock(). This results in an invalid page and we need to try again.
In particular, if we are relocating concurrently with aborting a transaction, this can result in a crash like the following:
BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 76 PID: 1411631 Comm: kworker/u322:5 Workqueue: events_unbound btrfs_reclaim_bgs_work RIP: 0010:set_page_extent_mapped+0x20/0xb0 RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246 RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880 RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0 R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000 R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die+0x78/0xc0 ? page_fault_oops+0x2a8/0x3a0 ? __switch_to+0x133/0x530 ? wq_worker_running+0xa/0x40 ? exc_page_fault+0x63/0x130 ? asm_exc_page_fault+0x22/0x30 ? set_page_extent_mapped+0x20/0xb0 relocate_file_extent_cluster+0x1a7/0x940 relocate_data_extent+0xaf/0x120 relocate_block_group+0x20f/0x480 btrfs_relocate_block_group+0x152/0x320 btrfs_relocate_chunk+0x3d/0x120 btrfs_reclaim_bgs_work+0x2ae/0x4e0 process_scheduled_works+0x184/0x370 worker_thread+0xc6/0x3e0 ? blk_add_timer+0xb0/0xb0 kthread+0xae/0xe0 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork+0x2f/0x40 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork_asm+0x11/0x20 </TASK>
This occurs because cleanup_one_transaction() calls destroy_delalloc_inodes() which calls invalidate_inode_pages2() which takes the folio_lock before setting mapping to NULL. We fail to check this, and subsequently call set_extent_mapping(), which assumes that mapping != NULL (in fact it asserts that in debug mode)
Note that the "fixes" patch here is not the one that introduced the race (the very first iteration of this code from 2009) but a more recent change that made this particular crash happen in practice.(CVE-2024-56758)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"perf-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-247.0.0.149.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-247.0.0.149.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"perf-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-247.0.0.149.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-247.0.0.149.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-247.0.0.149.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.\n\n\n\n\n(CVE-2024-24858)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: Create persistent IRQ handlers\n\nThe vfio-platform SET_IRQS ioctl currently allows loopback triggering of\nan interrupt before a signaling eventfd has been configured by the user,\nwhich thereby allows a NULL pointer dereference.\n\nRather than register the IRQ relative to a valid trigger, register all\nIRQs in a disabled state in the device open path. This allows mask\noperations on the IRQ to nest within the overall enable state governed\nby a valid eventfd signal. This decouples @masked, protected by the\n@locked spinlock from @trigger, protected via the @igate mutex.\n\nIn doing so, it\u0026apos;s guaranteed that changes to @trigger cannot race the\nIRQ handlers because the IRQ handler is synchronously disabled before\nmodifying the trigger, and loopback triggering of the IRQ via ioctl is\nsafe due to serialization with trigger changes via igate.\n\nFor compatibility, request_irq() failures are maintained to be local to\nthe SET_IRQS ioctl rather than a fatal error in the open device path.\nThis allows, for example, a userspace driver with polling mode support\nto continue to work regardless of moving the request_irq() call site.\nThis necessarily blocks all SET_IRQS access to the failed index.(CVE-2024-26813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: make sure to pull inner header in geneve_rx()\n\nsyzbot triggered a bug in geneve_rx() [1]\n\nIssue is similar to the one I fixed in commit 8d975c15c0cd\n(\u0026quot;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\u0026quot;)\n\nWe have to save skb-\u0026gt;network_header in a temporary variable\nin order to be able to recompute the network_header pointer\nafter a pskb_inet_may_pull() call.\n\npskb_inet_may_pull() makes sure the needed headers are in skb-\u0026gt;head.\n\n[1]\nBUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]\n BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n geneve_rx drivers/net/geneve.c:279 [inline]\n geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422\n udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604\n ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:461 [inline]\n ip_rcv_finish net/ipv4/ip_input.c:449 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core net/core/dev.c:5534 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648\n process_backlog+0x480/0x8b0 net/core/dev.c:5976\n __napi_poll+0xe3/0x980 net/core/dev.c:6576\n napi_poll net/core/dev.c:6645 [inline]\n net_rx_action+0x8b8/0x1870 net/core/dev.c:6778\n __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553\n do_softirq+0x9a/0xf0 kernel/softirq.c:454\n __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]\n __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x352/0x790 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1296 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783\n packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n packet_snd net/packet/af_packet.c:3024 [inline]\n packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\n\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\n\nThis resolves a kernel BUG reported by syzbot. Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\n\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\n\n\nThis patch (of 2):\n\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\n\nThere are two flaws involved in this issue.\n\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block(). This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\n\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state. This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\n\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above. Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26966)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-ipq8074: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - resolve race condition during AER recovery\n\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\n\nThis results in a KFENCE bug notice.\n\n BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n adf_device_reset_worker+0x38/0xa0 [intel_qat]\n process_one_work+0x173/0x340\n\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix OOB in nilfs_set_de_type\n\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\n\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\n\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\n\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied. Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error\n\nWhen ncm function is working and then stop usb0 interface for link down,\neth_stop() is called. At this piont, accidentally if usb transport error\nshould happen in usb_ep_enable(), \u0026apos;in_ep\u0026apos; and/or \u0026apos;out_ep\u0026apos; may not be enabled.\n\nAfter that, ncm_disable() is called to disable for ncm unbind\nbut gether_disconnect() is never called since \u0026apos;in_ep\u0026apos; is not enabled.\n\nAs the result, ncm object is released in ncm unbind\nbut \u0026apos;dev-\u0026gt;port_usb\u0026apos; associated to \u0026apos;ncm-\u0026gt;port\u0026apos; is not NULL.\n\nAnd when ncm bind again to recover netdev, ncm object is reallocated\nbut usb0 interface is already associated to previous released ncm object.\n\nTherefore, once usb0 interface is up and eth_start_xmit() is called,\nreleased ncm object is dereferrenced and it might cause use-after-free memory.\n\n[function unlink via configfs]\n usb0: eth_stop dev-\u0026gt;port_usb=ffffff9b179c3200\n --\u0026gt; error happens in usb_ep_enable().\n NCM: ncm_disable: ncm=ffffff9b179c3200\n --\u0026gt; no gether_disconnect() since ncm-\u0026gt;port.in_ep-\u0026gt;enabled is false.\n NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200\n NCM: ncm_free: ncm free ncm=ffffff9b179c3200 \u0026lt;-- released ncm\n\n[function link via configfs]\n NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000\n NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000\n NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0\n usb0: eth_open dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;-- previous released ncm\n usb0: eth_start dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;--\n eth_start_xmit()\n --\u0026gt; dev-\u0026gt;wrap()\n Unable to handle kernel paging request at virtual address dead00000000014f\n\nThis patch addresses the issue by checking if \u0026apos;ncm-\u0026gt;netdev\u0026apos; is not NULL at\nncm_disable() to call gether_disconnect() to deassociate \u0026apos;dev-\u0026gt;port_usb\u0026apos;.\nIt\u0026apos;s more reasonable to check \u0026apos;ncm-\u0026gt;netdev\u0026apos; to call gether_connect/disconnect\nrather than check \u0026apos;ncm-\u0026gt;port.in_ep-\u0026gt;enabled\u0026apos; since it might not be enabled\nbut the gether connection might be established.(CVE-2024-26996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: vmk80xx: fix incomplete endpoint checking\n\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\n\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\n\nThis patch has not been tested on real hardware.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\n\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Prevent release of buffer in I/O\n\nWhen a task waiting for completion of a Store Data operation is\ninterrupted, an attempt is made to halt this operation. If this attempt\nfails due to a hardware or firmware problem, there is a chance that the\nSCLP facility might store data into buffers referenced by the original\noperation at a later time.\n\nHandle this situation by not releasing the referenced data buffers if\nthe halt attempt fails. For current use cases, this might result in a\nleak of few pages of memory in case of a rare hardware/firmware\nmalfunction.(CVE-2024-44969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hdcp: Add encoder check in hdcp2_get_capability\n\nAdd encoder check in intel_hdcp2_get_capability to avoid\nnull pointer error.(CVE-2024-53050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()\n\nib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.\nThe driver needs to check whether it is a NULL pointer before\ndereferencing it.(CVE-2024-53226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: Fix NULL pointer dereference in object-\u0026gt;file\n\nAt present, the object-\u0026gt;file has the NULL pointer dereference problem in\nondemand-mode. The root cause is that the allocated fd and object-\u0026gt;file\nlifetime are inconsistent, and the user-space invocation to anon_fd uses\nobject-\u0026gt;file. Following is the process that triggers the issue:\n\n\t [write fd]\t\t\t\t[umount]\ncachefiles_ondemand_fd_write_iter\n\t\t\t\t fscache_cookie_state_machine\n\t\t\t\t\t cachefiles_withdraw_cookie\n if (!file) return -ENOBUFS\n\t\t\t\t\t cachefiles_clean_up_object\n\t\t\t\t\t cachefiles_unmark_inode_in_use\n\t\t\t\t\t fput(object-\u0026gt;file)\n\t\t\t\t\t object-\u0026gt;file = NULL\n // file NULL pointer dereference!\n __cachefiles_write(..., file, ...)\n\nFix this issue by add an additional reference count to the object-\u0026gt;file\nbefore write/llseek, and decrement after it finished.(CVE-2024-56549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write\n\nAn offset from client could be a negative value, It could allows\nto write data outside the bounds of the allocated buffer.\nNote that this issue is coming when setting\n\u0026apos;vfs objects = streams_xattr parameter\u0026apos; in ksmbd.conf..(CVE-2024-56626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3146 [inline]\n packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4091 [inline]\n slab_alloc_node mm/slub.c:4134 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n packet_snd net/packet/af_packet.c:3089 [inline]\n packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY\n\nSince commit 8f4f68e788c3 (\u0026quot;crypto: pcrypt - Fix hungtask for\nPADATA_RESET\u0026quot;), the pcrypt encryption and decryption operations return\n-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is\ngenerated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns\n-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.\nFix this issue by calling crypto layer directly without parallelization\nin that case.(CVE-2024-56690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: check folio mapping after unlock in relocate_one_folio()\n\nWhen we call btrfs_read_folio() to bring a folio uptodate, we unlock the\nfolio. The result of that is that a different thread can modify the\nmapping (like remove it with invalidate) before we call folio_lock().\nThis results in an invalid page and we need to try again.\n\nIn particular, if we are relocating concurrently with aborting a\ntransaction, this can result in a crash like the following:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP\n CPU: 76 PID: 1411631 Comm: kworker/u322:5\n Workqueue: events_unbound btrfs_reclaim_bgs_work\n RIP: 0010:set_page_extent_mapped+0x20/0xb0\n RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246\n RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880\n RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0\n R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000\n R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff\n FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x78/0xc0\n ? page_fault_oops+0x2a8/0x3a0\n ? __switch_to+0x133/0x530\n ? wq_worker_running+0xa/0x40\n ? exc_page_fault+0x63/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? set_page_extent_mapped+0x20/0xb0\n relocate_file_extent_cluster+0x1a7/0x940\n relocate_data_extent+0xaf/0x120\n relocate_block_group+0x20f/0x480\n btrfs_relocate_block_group+0x152/0x320\n btrfs_relocate_chunk+0x3d/0x120\n btrfs_reclaim_bgs_work+0x2ae/0x4e0\n process_scheduled_works+0x184/0x370\n worker_thread+0xc6/0x3e0\n ? blk_add_timer+0xb0/0xb0\n kthread+0xae/0xe0\n ? flush_tlb_kernel_range+0x90/0x90\n ret_from_fork+0x2f/0x40\n ? flush_tlb_kernel_range+0x90/0x90\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n\nThis occurs because cleanup_one_transaction() calls\ndestroy_delalloc_inodes() which calls invalidate_inode_pages2() which\ntakes the folio_lock before setting mapping to NULL. We fail to check\nthis, and subsequently call set_extent_mapping(), which assumes that\nmapping != NULL (in fact it asserts that in debug mode)\n\nNote that the \u0026quot;fixes\u0026quot; patch here is not the one that introduced the\nrace (the very first iteration of this code from 2009) but a more recent\nchange that made this particular crash happen in practice.(CVE-2024-56758)",
"id": "OESA-2025-1080",
"modified": "2026-08-06T11:08:10Z",
"published": "2025-01-24T11:08:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26813"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26857"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53050"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53226"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56626"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56648"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56690"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56758"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-24858",
"CVE-2024-26813",
"CVE-2024-26857",
"CVE-2024-26956",
"CVE-2024-26966",
"CVE-2024-26969",
"CVE-2024-26974",
"CVE-2024-26981",
"CVE-2024-26996",
"CVE-2024-27001",
"CVE-2024-44969",
"CVE-2024-50279",
"CVE-2024-53050",
"CVE-2024-53226",
"CVE-2024-56549",
"CVE-2024-56626",
"CVE-2024-56648",
"CVE-2024-56690",
"CVE-2024-56728",
"CVE-2024-56758"
]
}
OESA-2025-1081 (CVE-2024-24858)
Vulnerability from osv_openeuler – Published: 2025-01-24 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.
(CVE-2024-24858)
In the Linux kernel, the following vulnerability has been resolved:
sched/membarrier: reduce the ability to hammer on sys_membarrier
On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.(CVE-2024-26602)
In the Linux kernel, the following vulnerability has been resolved:
hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed
If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER handler cannot perform VF register successfully as the register call is received before netvsc_probe is finished. This is because we register register_netdevice_notifier() very early( even before vmbus_driver_register()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe.(CVE-2024-26820)
In the Linux kernel, the following vulnerability has been resolved:
geneve: make sure to pull inner header in geneve_rx()
syzbot triggered a bug in geneve_rx() [1]
Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
[1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch.
The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such.
This patch (of 2):
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted.
There are two flaws involved in this issue.
The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently.
The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing.
This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26966)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().
Only compile tested.(CVE-2024-26969)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug.
This results in a KFENCE bug notice.
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.(CVE-2024-26974)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix OOB in nilfs_set_de_type
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT".
static void nilfs_set_de_type(struct nilfs_dir_entry de, struct inode inode) { umode_t mode = inode->i_mode;
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}
However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.(CVE-2024-26981)
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...
Similar issue also found by Syzkaller:(CVE-2024-27001)
In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain:
sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries()
In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered.(CVE-2024-38547)
In the Linux kernel, the following vulnerability has been resolved:
media: stk1160: fix bounds checking in stk1160_copy_video()
The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true.
Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line.
To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes.(CVE-2024-38621)
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Prevent release of buffer in I/O
When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.
Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.(CVE-2024-44969)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix out-of-bounds access to the dirty bitset when resizing
dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.
Reproduce steps:
- create a cache device of 1024 cache blocks (128 bytes dirty bitset)
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
- shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)
dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131
(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0
(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by making the index post-incremented.(CVE-2024-50279)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hdcp: Add encoder check in hdcp2_get_capability
Add encoder check in intel_hdcp2_get_capability to avoid null pointer error.(CVE-2024-53050)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()
ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument. The driver needs to check whether it is a NULL pointer before dereferencing it.(CVE-2024-53226)
In the Linux kernel, the following vulnerability has been resolved:
cachefiles: Fix NULL pointer dereference in object->file
At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue:
[write fd] [umount]
cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...)
Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished.(CVE-2024-56549)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write
An offset from client could be a negative value, It could allows to write data outside the bounds of the allocated buffer. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf..(CVE-2024-56626)
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: avoid potential out-of-bound access in fill_frame_info()
syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one.
Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case.
BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY
Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.(CVE-2024-56690)
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c
Add error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56728)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: check folio mapping after unlock in relocate_one_folio()
When we call btrfs_read_folio() to bring a folio uptodate, we unlock the folio. The result of that is that a different thread can modify the mapping (like remove it with invalidate) before we call folio_lock(). This results in an invalid page and we need to try again.
In particular, if we are relocating concurrently with aborting a transaction, this can result in a crash like the following:
BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 76 PID: 1411631 Comm: kworker/u322:5 Workqueue: events_unbound btrfs_reclaim_bgs_work RIP: 0010:set_page_extent_mapped+0x20/0xb0 RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246 RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880 RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0 R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000 R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die+0x78/0xc0 ? page_fault_oops+0x2a8/0x3a0 ? __switch_to+0x133/0x530 ? wq_worker_running+0xa/0x40 ? exc_page_fault+0x63/0x130 ? asm_exc_page_fault+0x22/0x30 ? set_page_extent_mapped+0x20/0xb0 relocate_file_extent_cluster+0x1a7/0x940 relocate_data_extent+0xaf/0x120 relocate_block_group+0x20f/0x480 btrfs_relocate_block_group+0x152/0x320 btrfs_relocate_chunk+0x3d/0x120 btrfs_reclaim_bgs_work+0x2ae/0x4e0 process_scheduled_works+0x184/0x370 worker_thread+0xc6/0x3e0 ? blk_add_timer+0xb0/0xb0 kthread+0xae/0xe0 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork+0x2f/0x40 ? flush_tlb_kernel_range+0x90/0x90 ret_from_fork_asm+0x11/0x20 </TASK>
This occurs because cleanup_one_transaction() calls destroy_delalloc_inodes() which calls invalidate_inode_pages2() which takes the folio_lock before setting mapping to NULL. We fail to check this, and subsequently call set_extent_mapping(), which assumes that mapping != NULL (in fact it asserts that in debug mode)
Note that the "fixes" patch here is not the one that introduced the race (the very first iteration of this code from 2009) but a more recent change that made this particular crash happen in practice.(CVE-2024-56758)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-247.0.0.146.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-247.0.0.146.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-247.0.0.146.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.\n\n\n\n\n(CVE-2024-24858)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/membarrier: reduce the ability to hammer on sys_membarrier\n\nOn some systems, sys_membarrier can be very expensive, causing overall\nslowdowns for everything. So put a lock on the path in order to\nserialize the accesses to prevent the ability for this to be called at\ntoo high of a frequency and saturate the machine.(CVE-2024-26602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed\n\nIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER\nhandler cannot perform VF register successfully as the register call\nis received before netvsc_probe is finished. This is because we\nregister register_netdevice_notifier() very early( even before\nvmbus_driver_register()).\nTo fix this, we try to register each such matching VF( if it is visible\nas a netdevice) at the end of netvsc_probe.(CVE-2024-26820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: make sure to pull inner header in geneve_rx()\n\nsyzbot triggered a bug in geneve_rx() [1]\n\nIssue is similar to the one I fixed in commit 8d975c15c0cd\n(\u0026quot;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\u0026quot;)\n\nWe have to save skb-\u0026gt;network_header in a temporary variable\nin order to be able to recompute the network_header pointer\nafter a pskb_inet_may_pull() call.\n\npskb_inet_may_pull() makes sure the needed headers are in skb-\u0026gt;head.\n\n[1]\nBUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]\n BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n geneve_rx drivers/net/geneve.c:279 [inline]\n geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422\n udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604\n ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:461 [inline]\n ip_rcv_finish net/ipv4/ip_input.c:449 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core net/core/dev.c:5534 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648\n process_backlog+0x480/0x8b0 net/core/dev.c:5976\n __napi_poll+0xe3/0x980 net/core/dev.c:6576\n napi_poll net/core/dev.c:6645 [inline]\n net_rx_action+0x8b8/0x1870 net/core/dev.c:6778\n __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553\n do_softirq+0x9a/0xf0 kernel/softirq.c:454\n __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]\n __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x352/0x790 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1296 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783\n packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n packet_snd net/packet/af_packet.c:3024 [inline]\n packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\n\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\n\nThis resolves a kernel BUG reported by syzbot. Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\n\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\n\n\nThis patch (of 2):\n\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\n\nThere are two flaws involved in this issue.\n\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block(). This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\n\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state. This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\n\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above. Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26966)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-ipq8074: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.(CVE-2024-26969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - resolve race condition during AER recovery\n\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\n\nThis results in a KFENCE bug notice.\n\n BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n adf_device_reset_worker+0x38/0xa0 [intel_qat]\n process_one_work+0x173/0x340\n\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix OOB in nilfs_set_de_type\n\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\n\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\n\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\n\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied. Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: vmk80xx: fix incomplete endpoint checking\n\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\n\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\n\nThis patch has not been tested on real hardware.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\n\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries\n\nThe allocation failure of mycs-\u0026gt;yuv_scaler_binary in load_video_binaries()\nis followed with a dereference of mycs-\u0026gt;yuv_scaler_binary after the\nfollowing call chain:\n\nsh_css_pipe_load_binaries()\n |-\u0026gt; load_video_binaries(mycs-\u0026gt;yuv_scaler_binary == NULL)\n |\n |-\u0026gt; sh_css_pipe_unload_binaries()\n |-\u0026gt; unload_video_binaries()\n\nIn unload_video_binaries(), it calls to ia_css_binary_unload with argument\n\u0026amp;pipe-\u0026gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the\nsame memory slot as mycs-\u0026gt;yuv_scaler_binary. Thus, a null-pointer\ndereference is triggered.(CVE-2024-38547)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\n\nThe subtract in this condition is reversed. The -\u0026gt;length is the length\nof the buffer. The -\u0026gt;bytesused is how many bytes we have copied thus\nfar. When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value. That means the overflow check is never\ntrue.\n\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;. Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved. You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\n\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn. Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/sclp: Prevent release of buffer in I/O\n\nWhen a task waiting for completion of a Store Data operation is\ninterrupted, an attempt is made to halt this operation. If this attempt\nfails due to a hardware or firmware problem, there is a chance that the\nSCLP facility might store data into buffers referenced by the original\noperation at a later time.\n\nHandle this situation by not releasing the referenced data buffers if\nthe halt attempt fails. For current use cases, this might result in a\nleak of few pages of memory in case of a rare hardware/firmware\nmalfunction.(CVE-2024-44969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hdcp: Add encoder check in hdcp2_get_capability\n\nAdd encoder check in intel_hdcp2_get_capability to avoid\nnull pointer error.(CVE-2024-53050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()\n\nib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.\nThe driver needs to check whether it is a NULL pointer before\ndereferencing it.(CVE-2024-53226)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: Fix NULL pointer dereference in object-\u0026gt;file\n\nAt present, the object-\u0026gt;file has the NULL pointer dereference problem in\nondemand-mode. The root cause is that the allocated fd and object-\u0026gt;file\nlifetime are inconsistent, and the user-space invocation to anon_fd uses\nobject-\u0026gt;file. Following is the process that triggers the issue:\n\n\t [write fd]\t\t\t\t[umount]\ncachefiles_ondemand_fd_write_iter\n\t\t\t\t fscache_cookie_state_machine\n\t\t\t\t\t cachefiles_withdraw_cookie\n if (!file) return -ENOBUFS\n\t\t\t\t\t cachefiles_clean_up_object\n\t\t\t\t\t cachefiles_unmark_inode_in_use\n\t\t\t\t\t fput(object-\u0026gt;file)\n\t\t\t\t\t object-\u0026gt;file = NULL\n // file NULL pointer dereference!\n __cachefiles_write(..., file, ...)\n\nFix this issue by add an additional reference count to the object-\u0026gt;file\nbefore write/llseek, and decrement after it finished.(CVE-2024-56549)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write\n\nAn offset from client could be a negative value, It could allows\nto write data outside the bounds of the allocated buffer.\nNote that this issue is coming when setting\n\u0026apos;vfs objects = streams_xattr parameter\u0026apos; in ksmbd.conf..(CVE-2024-56626)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hsr: avoid potential out-of-bound access in fill_frame_info()\n\nsyzbot is able to feed a packet with 14 bytes, pretending\nit is a vlan one.\n\nSince fill_frame_info() is relying on skb-\u0026gt;mac_len already,\nextend the check to cover this case.\n\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n fill_frame_info net/hsr/hsr_forward.c:709 [inline]\n hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724\n hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606\n __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3146 [inline]\n packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4091 [inline]\n slab_alloc_node mm/slub.c:4134 [inline]\n kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n alloc_skb include/linux/skbuff.h:1323 [inline]\n alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881\n packet_alloc_skb net/packet/af_packet.c:2995 [inline]\n packet_snd net/packet/af_packet.c:3089 [inline]\n packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:726\n __sys_sendto+0x594/0x750 net/socket.c:2197\n __do_sys_sendto net/socket.c:2204 [inline]\n __se_sys_sendto net/socket.c:2200 [inline]\n __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200\n x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY\n\nSince commit 8f4f68e788c3 (\u0026quot;crypto: pcrypt - Fix hungtask for\nPADATA_RESET\u0026quot;), the pcrypt encryption and decryption operations return\n-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is\ngenerated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns\n-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.\nFix this issue by calling crypto layer directly without parallelization\nin that case.(CVE-2024-56690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: check folio mapping after unlock in relocate_one_folio()\n\nWhen we call btrfs_read_folio() to bring a folio uptodate, we unlock the\nfolio. The result of that is that a different thread can modify the\nmapping (like remove it with invalidate) before we call folio_lock().\nThis results in an invalid page and we need to try again.\n\nIn particular, if we are relocating concurrently with aborting a\ntransaction, this can result in a crash like the following:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP\n CPU: 76 PID: 1411631 Comm: kworker/u322:5\n Workqueue: events_unbound btrfs_reclaim_bgs_work\n RIP: 0010:set_page_extent_mapped+0x20/0xb0\n RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246\n RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880\n RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0\n R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000\n R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff\n FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x78/0xc0\n ? page_fault_oops+0x2a8/0x3a0\n ? __switch_to+0x133/0x530\n ? wq_worker_running+0xa/0x40\n ? exc_page_fault+0x63/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? set_page_extent_mapped+0x20/0xb0\n relocate_file_extent_cluster+0x1a7/0x940\n relocate_data_extent+0xaf/0x120\n relocate_block_group+0x20f/0x480\n btrfs_relocate_block_group+0x152/0x320\n btrfs_relocate_chunk+0x3d/0x120\n btrfs_reclaim_bgs_work+0x2ae/0x4e0\n process_scheduled_works+0x184/0x370\n worker_thread+0xc6/0x3e0\n ? blk_add_timer+0xb0/0xb0\n kthread+0xae/0xe0\n ? flush_tlb_kernel_range+0x90/0x90\n ret_from_fork+0x2f/0x40\n ? flush_tlb_kernel_range+0x90/0x90\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n\nThis occurs because cleanup_one_transaction() calls\ndestroy_delalloc_inodes() which calls invalidate_inode_pages2() which\ntakes the folio_lock before setting mapping to NULL. We fail to check\nthis, and subsequently call set_extent_mapping(), which assumes that\nmapping != NULL (in fact it asserts that in debug mode)\n\nNote that the \u0026quot;fixes\u0026quot; patch here is not the one that introduced the\nrace (the very first iteration of this code from 2009) but a more recent\nchange that made this particular crash happen in practice.(CVE-2024-56758)",
"id": "OESA-2025-1081",
"modified": "2026-08-06T11:08:10Z",
"published": "2025-01-24T11:08:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24858"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26820"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26857"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26974"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38547"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53050"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53226"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56626"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56648"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56690"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56758"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-24858",
"CVE-2024-26602",
"CVE-2024-26820",
"CVE-2024-26857",
"CVE-2024-26956",
"CVE-2024-26966",
"CVE-2024-26969",
"CVE-2024-26974",
"CVE-2024-26981",
"CVE-2024-27001",
"CVE-2024-38547",
"CVE-2024-38621",
"CVE-2024-44969",
"CVE-2024-50279",
"CVE-2024-53050",
"CVE-2024-53226",
"CVE-2024-56549",
"CVE-2024-56626",
"CVE-2024-56648",
"CVE-2024-56690",
"CVE-2024-56728",
"CVE-2024-56758"
]
}
OESA-2025-1094 (CVE-2022-48917)
Vulnerability from osv_openeuler – Published: 2025-02-08 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min
While the $val/$val2 values passed in from userspace are always >= 0 integers, the limits of the control can be signed integers and the $min can be non-zero and less than zero. To correctly validate $val/$val2 against platform_max, add the $min offset to val first.(CVE-2022-48917)
In the Linux kernel, the following vulnerability has been resolved:
tcp: do not accept ACK of bytes we never sent
This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow.
ACK seq validation is currently following RFC 5961 5.2 guidelines:
The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent.
This greatly improves TCP security at a little cost.
I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC.
tp->bytes_acked was added in linux-4.2
Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand:
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0
// ---------------- Handshake ------------------- //
// when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server.
+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4
// For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997
// Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535
// After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001(CVE-2023-52881)
A race condition was found in the Linux kernel's net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.
(CVE-2024-24857)
A race condition was found in the Linux kernel's net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.
(CVE-2024-24859)
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: Prevent UAF in proc_cpuset_show()
An UAF can happen when /proc/cpuset is read as reported in [1].
This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc/<pid>/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly.
The race that cause this bug can be shown as below:
(umount) | (cat /proc/<pid>/cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..);
When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.
The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed.
Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section. To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css.
[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix out-of-bounds access to the dirty bitset when resizing
dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.
Reproduce steps:
- create a cache device of 1024 cache blocks (128 bytes dirty bitset)
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
- shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)
dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131
(...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0
(...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by making the index post-incremented.(CVE-2024-50279)
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Fix slab-use-after-free read in sg_release()
Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407
In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp.
After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.
Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures:
-
No references to sfp or sdp occur after the reference count is decremented.
-
Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release().
The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().(CVE-2024-56631)
In the Linux kernel, the following vulnerability has been resolved:
net: Fix icmp host relookup triggering ip_rt_bug
arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:
WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: <IRQ> ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90
The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1
icmp_route_lookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = ip_rt_bug) to skb for DESTUNREACH.
For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).
Skip icmp relookup for locally generated packets to fix it.(CVE-2024-56647)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL.(CVE-2024-56688)
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY
Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case.(CVE-2024-56690)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv
When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is the dangling pointer.
During the remounting process, the pointer dqi_priv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOT_SUSPENDED flag instead of setting the DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2_get_next_id is called and only checks the quota usage flags and not the quota suspended flags.
To fix this, I set dqi_priv to null when it is freed after remounting with read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.
| URL | Type | |||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2502.1.0.0314.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2502.1.0.0314.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2502.1.0.0314.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-2502.1.0.0314.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\nASoC: ops: Shift tested values in snd_soc_put_volsw() by +min\n\nWhile the $val/$val2 values passed in from userspace are always \u0026gt;= 0\nintegers, the limits of the control can be signed integers and the $min\ncan be non-zero and less than zero. To correctly validate $val/$val2\nagainst platform_max, add the $min offset to val first.(CVE-2022-48917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: do not accept ACK of bytes we never sent\n\nThis patch is based on a detailed report and ideas from Yepeng Pan\nand Christian Rossow.\n\nACK seq validation is currently following RFC 5961 5.2 guidelines:\n\n The ACK value is considered acceptable only if\n it is in the range of ((SND.UNA - MAX.SND.WND) \u0026lt;= SEG.ACK \u0026lt;=\n SND.NXT). All incoming segments whose ACK value doesn\u0026apos;t satisfy the\n above condition MUST be discarded and an ACK sent back. It needs to\n be noted that RFC 793 on page 72 (fifth check) says: \u0026quot;If the ACK is a\n duplicate (SEG.ACK \u0026lt; SND.UNA), it can be ignored. If the ACK\n acknowledges something not yet sent (SEG.ACK \u0026gt; SND.NXT) then send an\n ACK, drop the segment, and return\u0026quot;. The \u0026quot;ignored\u0026quot; above implies that\n the processing of the incoming data segment continues, which means\n the ACK value is treated as acceptable. This mitigation makes the\n ACK check more stringent since any ACK \u0026lt; SND.UNA wouldn\u0026apos;t be\n accepted, instead only ACKs that are in the range ((SND.UNA -\n MAX.SND.WND) \u0026lt;= SEG.ACK \u0026lt;= SND.NXT) get through.\n\nThis can be refined for new (and possibly spoofed) flows,\nby not accepting ACK for bytes that were never sent.\n\nThis greatly improves TCP security at a little cost.\n\nI added a Fixes: tag to make sure this patch will reach stable trees,\neven if the \u0026apos;blamed\u0026apos; patch was adhering to the RFC.\n\ntp-\u0026gt;bytes_acked was added in linux-4.2\n\nFollowing packetdrill test (courtesy of Yepeng Pan) shows\nthe issue at hand:\n\n0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3\n+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\n+0 bind(3, ..., ...) = 0\n+0 listen(3, 1024) = 0\n\n// ---------------- Handshake ------------------- //\n\n// when window scale is set to 14 the window size can be extended to\n// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet\n// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)\n// ,though this ack number acknowledges some data never\n// sent by the server.\n\n+0 \u0026lt; S 0:0(0) win 65535 \u0026lt;mss 1400,nop,wscale 14\u0026gt;\n+0 \u0026gt; S. 0:0(0) ack 1 \u0026lt;...\u0026gt;\n+0 \u0026lt; . 1:1(0) ack 1 win 65535\n+0 accept(3, ..., ...) = 4\n\n// For the established connection, we send an ACK packet,\n// the ack packet uses ack number 1 - 1073725300 + 2^32,\n// where 2^32 is used to wrap around.\n// Note: we used 1073725300 instead of 1073725440 to avoid possible\n// edge cases.\n// 1 - 1073725300 + 2^32 = 3221241997\n\n// Oops, old kernels happily accept this packet.\n+0 \u0026lt; . 1:1001(1000) ack 3221241997 win 65535\n\n// After the kernel fix the following will be replaced by a challenge ACK,\n// and prior malicious frame would be dropped.\n+0 \u0026gt; . 1:1(0) ack 1001(CVE-2023-52881)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.\n\n\n\n\n(CVE-2024-24857)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.\n\n\n\n\n\n\n\n(CVE-2024-24859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: Prevent UAF in proc_cpuset_show()\n\nAn UAF can happen when /proc/cpuset is read as reported in [1].\n\nThis can be reproduced by the following methods:\n1.add an mdelay(1000) before acquiring the cgroup_lock In the\n cgroup_path_ns function.\n2.$cat /proc/\u0026lt;pid\u0026gt;/cpuset repeatly.\n3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/\n$umount /sys/fs/cgroup/cpuset/ repeatly.\n\nThe race that cause this bug can be shown as below:\n\n(umount)\t\t|\t(cat /proc/\u0026lt;pid\u0026gt;/cpuset)\ncss_release\t\t|\tproc_cpuset_show\ncss_release_work_fn\t|\tcss = task_get_css(tsk, cpuset_cgrp_id);\ncss_free_rwork_fn\t|\tcgroup_path_ns(css-\u0026gt;cgroup, ...);\ncgroup_destroy_root\t|\tmutex_lock(\u0026amp;cgroup_mutex);\nrebind_subsystems\t|\ncgroup_free_root \t|\n\t\t\t|\t// cgrp was freed, UAF\n\t\t\t|\tcgroup_path_ns_locked(cgrp,..);\n\nWhen the cpuset is initialized, the root node top_cpuset.css.cgrp\nwill point to \u0026amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will\nallocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated\n\u0026amp;cgroup_root.cgrp. When the umount operation is executed,\ntop_cpuset.css.cgrp will be rebound to \u0026amp;cgrp_dfl_root.cgrp.\n\nThe problem is that when rebinding to cgrp_dfl_root, there are cases\nwhere the cgroup_root allocated by setting up the root for cgroup v1\nis cached. This could lead to a Use-After-Free (UAF) if it is\nsubsequently freed. The descendant cgroups of cgroup v1 can only be\nfreed after the css is released. However, the css of the root will never\nbe released, yet the cgroup_root should be freed when it is unmounted.\nThis means that obtaining a reference to the css of the root does\nnot guarantee that css.cgrp-\u0026gt;root will not be freed.\n\nFix this problem by using rcu_read_lock in proc_cpuset_show().\nAs cgroup_root is kfree_rcu after commit d23b5c577715\n(\u0026quot;cgroup: Make operations on the cgroup root_list RCU safe\u0026quot;),\ncss-\u0026gt;cgroup won\u0026apos;t be freed during the critical section.\nTo call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to\nreplace task_get_css with task_css.\n\n[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix out-of-bounds access to the dirty bitset when resizing\n\ndm-cache checks the dirty bits of the cache blocks to be dropped when\nshrinking the fast device, but an index bug in bitset iteration causes\nout-of-bounds access.\n\nReproduce steps:\n\n1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\n2. shrink the fast device to 512 cache blocks, triggering out-of-bounds\n access to the dirty bitset (offset 0x80)\n\ndmsetup suspend cache\ndmsetup reload cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup resume cdata\ndmsetup resume cache\n\nKASAN reports:\n\n BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0\n Read of size 8 at addr ffffc900000f3080 by task dmsetup/131\n\n (...snip...)\n The buggy address belongs to the virtual mapping at\n [ffffc900000f3000, ffffc900000f5000) created by:\n cache_ctr+0x176a/0x35f0\n\n (...snip...)\n Memory state around the buggy address:\n ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ^\n ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n\nFix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Fix slab-use-after-free read in sg_release()\n\nFix a use-after-free bug in sg_release(), detected by syzbot with KASAN:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30\nkernel/locking/lockdep.c:5838\n__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912\nsg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407\n\nIn sg_release(), the function kref_put(\u0026amp;sfp-\u0026gt;f_ref, sg_remove_sfp) is\ncalled before releasing the open_rel_lock mutex. The kref_put() call may\ndecrement the reference count of sfp to zero, triggering its cleanup\nthrough sg_remove_sfp(). This cleanup includes scheduling deferred work\nvia sg_remove_sfp_usercontext(), which ultimately frees sfp.\n\nAfter kref_put(), sg_release() continues to unlock open_rel_lock and may\nreference sfp or sdp. If sfp has already been freed, this results in a\nslab-use-after-free error.\n\nMove the kref_put(\u0026amp;sfp-\u0026gt;f_ref, sg_remove_sfp) call after unlocking the\nopen_rel_lock mutex. This ensures:\n\n - No references to sfp or sdp occur after the reference count is\n decremented.\n\n - Cleanup functions such as sg_remove_sfp() and\n sg_remove_sfp_usercontext() can safely execute without impacting the\n mutex handling in sg_release().\n\nThe fix has been tested and validated by syzbot. This patch closes the\nbug reported at the following syzkaller link and ensures proper\nsequencing of resource cleanup and mutex operations, eliminating the\nrisk of use-after-free errors in sg_release().(CVE-2024-56631)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: Fix icmp host relookup triggering ip_rt_bug\n\narp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:\n\nWARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20\nModules linked in:\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:ip_rt_bug+0x14/0x20\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n ip_send_skb+0x14/0x40\n __icmp_send+0x42d/0x6a0\n ipv4_link_failure+0xe2/0x1d0\n arp_error_report+0x3c/0x50\n neigh_invalidate+0x8d/0x100\n neigh_timer_handler+0x2e1/0x330\n call_timer_fn+0x21/0x120\n __run_timer_base.part.0+0x1c9/0x270\n run_timer_softirq+0x4c/0x80\n handle_softirqs+0xac/0x280\n irq_exit_rcu+0x62/0x80\n sysvec_apic_timer_interrupt+0x77/0x90\n\nThe script below reproduces this scenario:\nip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \\\n\tdir out priority 0 ptype main flag localok icmp\nip l a veth1 type veth\nip a a 192.168.141.111/24 dev veth0\nip l s veth0 up\nping 192.168.141.155 -c 1\n\nicmp_route_lookup() create input routes for locally generated packets\nwhile xfrm relookup ICMP traffic.Then it will set input route\n(dst-\u0026gt;out = ip_rt_bug) to skb for DESTUNREACH.\n\nFor ICMP err triggered by locally generated packets, dst-\u0026gt;dev of output\nroute is loopback. Generally, xfrm relookup verification is not required\non loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).\n\nSkip icmp relookup for locally generated packets to fix it.(CVE-2024-56647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY\n\nSince commit 8f4f68e788c3 (\u0026quot;crypto: pcrypt - Fix hungtask for\nPADATA_RESET\u0026quot;), the pcrypt encryption and decryption operations return\n-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is\ngenerated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns\n-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.\nFix this issue by calling crypto layer directly without parallelization\nin that case.(CVE-2024-56690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota. Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed. Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)",
"id": "OESA-2025-1094",
"modified": "2026-08-06T11:08:11Z",
"published": "2025-02-08T11:08:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1094"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48917"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52881"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24857"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56631"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56647"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56690"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
}
],
"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-48917",
"CVE-2023-52881",
"CVE-2024-24857",
"CVE-2024-24859",
"CVE-2024-43853",
"CVE-2024-50279",
"CVE-2024-56631",
"CVE-2024-56647",
"CVE-2024-56688",
"CVE-2024-56690",
"CVE-2024-57892"
]
}
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.