Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-50210 (GCVE-0-2024-50210)
Vulnerability from cvelistv5 – Published: 2024-11-08 06:08 – Updated: 2026-05-12 12:00- CWE-667 - Improper Locking
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
29f085345cde24566efb751f39e5d367c381c584 , < d005400262ddaf1ca1666bbcd1acf42fe81d57ce
(git)
Affected: e0c966bd3e31911b57ef76cec4c5796ebd88e512 , < a8219446b95a859488feaade674d13f9efacfa32 (git) Affected: 673a1c5a2998acbd429d6286e6cad10f17f4f073 , < c7fcfdba35abc9f39b83080c2bce398dad13a943 (git) Affected: c8789fbe2bbf75845e45302cba6ffa44e1884d01 , < e56e0ec1b79f5a6272c6e78b36e9d593aa0449af (git) Affected: 27abbde44b6e71ee3891de13e1a228aa7ce95bfe , < 5f063bbf1ee6b01611c016b54e050a41506eb794 (git) Affected: a3f169e398215e71361774d13bf91a0101283ac2 , < 1ba33b327c3f88a7baee598979d73ab5b44d41cc (git) Affected: 1ff7247101af723731ea42ed565d54fb8f341264 , < b27330128eca25179637c1816d5a72d6cc408c66 (git) Affected: d8794ac20a299b647ba9958f6d657051fc51a540 , < 6e62807c7fbb3c758d233018caf94dfea9c65dbd (git) |
guessed | |
| Linux | Linux |
Affected:
5.10.228 , < 5.10.229
(semver)
Affected: 5.15.169 , < 5.15.170 (semver) Affected: 6.1.114 , < 6.1.115 (semver) Affected: 6.6.58 , < 6.6.59 (semver) Affected: 6.11.5 , < 6.11.6 (semver) |
guessed | |
| Siemens | SIMATIC S7-1500 TM MFP - GNU/Linux subsystem |
Affected:
0 , < *
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2024-50210",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:17:22.253155Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-667",
"description": "CWE-667 Improper Locking",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T20:27:06.056Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:27:05.200Z",
"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"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T12:00:28.952Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"x_adpType": "supplier"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/time/posix-clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d005400262ddaf1ca1666bbcd1acf42fe81d57ce",
"status": "affected",
"version": "29f085345cde24566efb751f39e5d367c381c584",
"versionType": "git"
},
{
"lessThan": "a8219446b95a859488feaade674d13f9efacfa32",
"status": "affected",
"version": "e0c966bd3e31911b57ef76cec4c5796ebd88e512",
"versionType": "git"
},
{
"lessThan": "c7fcfdba35abc9f39b83080c2bce398dad13a943",
"status": "affected",
"version": "673a1c5a2998acbd429d6286e6cad10f17f4f073",
"versionType": "git"
},
{
"lessThan": "e56e0ec1b79f5a6272c6e78b36e9d593aa0449af",
"status": "affected",
"version": "c8789fbe2bbf75845e45302cba6ffa44e1884d01",
"versionType": "git"
},
{
"lessThan": "5f063bbf1ee6b01611c016b54e050a41506eb794",
"status": "affected",
"version": "27abbde44b6e71ee3891de13e1a228aa7ce95bfe",
"versionType": "git"
},
{
"lessThan": "1ba33b327c3f88a7baee598979d73ab5b44d41cc",
"status": "affected",
"version": "a3f169e398215e71361774d13bf91a0101283ac2",
"versionType": "git"
},
{
"lessThan": "b27330128eca25179637c1816d5a72d6cc408c66",
"status": "affected",
"version": "1ff7247101af723731ea42ed565d54fb8f341264",
"versionType": "git"
},
{
"lessThan": "6e62807c7fbb3c758d233018caf94dfea9c65dbd",
"status": "affected",
"version": "d8794ac20a299b647ba9958f6d657051fc51a540",
"versionType": "git"
}
]
},
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/time/posix-clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5.10.229",
"status": "affected",
"version": "5.10.228",
"versionType": "semver"
},
{
"lessThan": "5.15.170",
"status": "affected",
"version": "5.15.169",
"versionType": "semver"
},
{
"lessThan": "6.1.115",
"status": "affected",
"version": "6.1.114",
"versionType": "semver"
},
{
"lessThan": "6.6.59",
"status": "affected",
"version": "6.6.58",
"versionType": "semver"
},
{
"lessThan": "6.11.6",
"status": "affected",
"version": "6.11.5",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.229",
"versionStartIncluding": "5.10.228",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.170",
"versionStartIncluding": "5.15.169",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.115",
"versionStartIncluding": "6.1.114",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.59",
"versionStartIncluding": "6.6.58",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.6",
"versionStartIncluding": "6.11.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nposix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()\n\nIf get_clock_desc() succeeds, it calls fget() for the clockid\u0027s fd,\nand get the clk-\u003erwsem read lock, so the error path should release\nthe lock to make the lock balance and fput the clockid\u0027s fd to make\nthe refcount balance and release the fd related resource.\n\nHowever the below commit left the error path locked behind resulting in\nunbalanced locking. Check timespec64_valid_strict() before\nget_clock_desc() to fix it, because the \"ts\" is not changed\nafter that.\n\n[pabeni@redhat.com: fixed commit message typo]"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:47:33.314Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/d005400262ddaf1ca1666bbcd1acf42fe81d57ce"
},
{
"url": "https://git.kernel.org/stable/c/a8219446b95a859488feaade674d13f9efacfa32"
},
{
"url": "https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943"
},
{
"url": "https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593aa0449af"
},
{
"url": "https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a41506eb794"
},
{
"url": "https://git.kernel.org/stable/c/1ba33b327c3f88a7baee598979d73ab5b44d41cc"
},
{
"url": "https://git.kernel.org/stable/c/b27330128eca25179637c1816d5a72d6cc408c66"
},
{
"url": "https://git.kernel.org/stable/c/6e62807c7fbb3c758d233018caf94dfea9c65dbd"
}
],
"title": "posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-50210",
"datePublished": "2024-11-08T06:08:00.319Z",
"dateReserved": "2024-10-21T19:36:19.970Z",
"dateUpdated": "2026-05-12T12:00:28.952Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-50210",
"date": "2026-09-25",
"epss": "0.00172",
"percentile": "0.05799"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/time/posix-clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d005400262ddaf1ca1666bbcd1acf42fe81d57ce",
"status": "affected",
"version": "29f085345cde24566efb751f39e5d367c381c584",
"versionType": "git"
},
{
"lessThan": "a8219446b95a859488feaade674d13f9efacfa32",
"status": "affected",
"version": "e0c966bd3e31911b57ef76cec4c5796ebd88e512",
"versionType": "git"
},
{
"lessThan": "c7fcfdba35abc9f39b83080c2bce398dad13a943",
"status": "affected",
"version": "673a1c5a2998acbd429d6286e6cad10f17f4f073",
"versionType": "git"
},
{
"lessThan": "e56e0ec1b79f5a6272c6e78b36e9d593aa0449af",
"status": "affected",
"version": "c8789fbe2bbf75845e45302cba6ffa44e1884d01",
"versionType": "git"
},
{
"lessThan": "5f063bbf1ee6b01611c016b54e050a41506eb794",
"status": "affected",
"version": "27abbde44b6e71ee3891de13e1a228aa7ce95bfe",
"versionType": "git"
},
{
"lessThan": "1ba33b327c3f88a7baee598979d73ab5b44d41cc",
"status": "affected",
"version": "a3f169e398215e71361774d13bf91a0101283ac2",
"versionType": "git"
},
{
"lessThan": "b27330128eca25179637c1816d5a72d6cc408c66",
"status": "affected",
"version": "1ff7247101af723731ea42ed565d54fb8f341264",
"versionType": "git"
},
{
"lessThan": "6e62807c7fbb3c758d233018caf94dfea9c65dbd",
"status": "affected",
"version": "d8794ac20a299b647ba9958f6d657051fc51a540",
"versionType": "git"
}
]
},
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/time/posix-clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5.10.229",
"status": "affected",
"version": "5.10.228",
"versionType": "semver"
},
{
"lessThan": "5.15.170",
"status": "affected",
"version": "5.15.169",
"versionType": "semver"
},
{
"lessThan": "6.1.115",
"status": "affected",
"version": "6.1.114",
"versionType": "semver"
},
{
"lessThan": "6.6.59",
"status": "affected",
"version": "6.6.58",
"versionType": "semver"
},
{
"lessThan": "6.11.6",
"status": "affected",
"version": "6.11.5",
"versionType": "semver"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "7CEF9F93-A67A-45C9-9C51-0024664ACC19",
"versionEndExcluding": "5.11",
"versionStartIncluding": "5.10.228",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:5.15.169:*:*:*:*:*:*:*",
"matchCriteriaId": "65E5B4C5-20C7-42FD-B670-6B09641CC073",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.1.114:*:*:*:*:*:*:*",
"matchCriteriaId": "CFC6719E-D39A-44B0-90DD-F606EE505404",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.6.58:*:*:*:*:*:*:*",
"matchCriteriaId": "38BA5D36-31FC-4EF3-9E92-9B67AB6F2D42",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.11.5:*:*:*:*:*:*:*",
"matchCriteriaId": "101C7DA2-28FF-4CC0-A476-2C8D49CD2AC5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*",
"matchCriteriaId": "E0F717D8-3014-4F84-8086-0124B2111379",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nposix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()\n\nIf get_clock_desc() succeeds, it calls fget() for the clockid\u0027s fd,\nand get the clk-\u003erwsem read lock, so the error path should release\nthe lock to make the lock balance and fput the clockid\u0027s fd to make\nthe refcount balance and release the fd related resource.\n\nHowever the below commit left the error path locked behind resulting in\nunbalanced locking. Check timespec64_valid_strict() before\nget_clock_desc() to fix it, because the \"ts\" is not changed\nafter that.\n\n[pabeni@redhat.com: fixed commit message typo]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: posix-clock: posix-clock: Corregir bloqueo desequilibrado en pc_clock_settime() Si get_clock_desc() tiene \u00e9xito, llama a fget() para el fd del clockid y obtiene el bloqueo de lectura clk-\u0026gt;rwsem, por lo que la ruta de error deber\u00eda liberar el bloqueo para equilibrar el bloqueo y fput el fd del clockid para equilibrar el refcount y liberar el recurso relacionado con el fd. Sin embargo, la siguiente confirmaci\u00f3n dej\u00f3 la ruta de error bloqueada, lo que result\u00f3 en un bloqueo desequilibrado. Verifique timespec64_valid_strict() antes de get_clock_desc() para corregirlo, porque el \"ts\" no se cambia despu\u00e9s de eso. [pabeni@redhat.com: se corrigi\u00f3 un error tipogr\u00e1fico en el mensaje de confirmaci\u00f3n]"
}
],
"id": "CVE-2024-50210",
"lastModified": "2026-06-17T08:03:52.943",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-50210",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:17:22.253155Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-11-08T06:15:17.350",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1ba33b327c3f88a7baee598979d73ab5b44d41cc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a41506eb794"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6e62807c7fbb3c758d233018caf94dfea9c65dbd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a8219446b95a859488feaade674d13f9efacfa32"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b27330128eca25179637c1816d5a72d6cc408c66"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d005400262ddaf1ca1666bbcd1acf42fe81d57ce"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593aa0449af"
},
{
"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"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2025-11-21T14:20:44+00:00",
"cve": "CVE-2024-50210",
"id": "CVE-2024-50210",
"initial_release_date": "2024-11-08T00:00:00+00:00",
"product_status:known_affected": "42",
"product_status:known_not_affected": "156",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-50210.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T22:27:05.200Z",
"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"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T12:00:28.952Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
}
],
"x_adpType": "supplier"
},
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2024-50210",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:17:22.253155Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-667",
"description": "CWE-667 Improper Locking",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T15:22:30.830Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/time/posix-clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d005400262ddaf1ca1666bbcd1acf42fe81d57ce",
"status": "affected",
"version": "29f085345cde24566efb751f39e5d367c381c584",
"versionType": "git"
},
{
"lessThan": "a8219446b95a859488feaade674d13f9efacfa32",
"status": "affected",
"version": "e0c966bd3e31911b57ef76cec4c5796ebd88e512",
"versionType": "git"
},
{
"lessThan": "c7fcfdba35abc9f39b83080c2bce398dad13a943",
"status": "affected",
"version": "673a1c5a2998acbd429d6286e6cad10f17f4f073",
"versionType": "git"
},
{
"lessThan": "e56e0ec1b79f5a6272c6e78b36e9d593aa0449af",
"status": "affected",
"version": "c8789fbe2bbf75845e45302cba6ffa44e1884d01",
"versionType": "git"
},
{
"lessThan": "5f063bbf1ee6b01611c016b54e050a41506eb794",
"status": "affected",
"version": "27abbde44b6e71ee3891de13e1a228aa7ce95bfe",
"versionType": "git"
},
{
"lessThan": "1ba33b327c3f88a7baee598979d73ab5b44d41cc",
"status": "affected",
"version": "a3f169e398215e71361774d13bf91a0101283ac2",
"versionType": "git"
},
{
"lessThan": "b27330128eca25179637c1816d5a72d6cc408c66",
"status": "affected",
"version": "1ff7247101af723731ea42ed565d54fb8f341264",
"versionType": "git"
},
{
"lessThan": "6e62807c7fbb3c758d233018caf94dfea9c65dbd",
"status": "affected",
"version": "d8794ac20a299b647ba9958f6d657051fc51a540",
"versionType": "git"
}
]
},
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/time/posix-clock.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5.10.229",
"status": "affected",
"version": "5.10.228",
"versionType": "semver"
},
{
"lessThan": "5.15.170",
"status": "affected",
"version": "5.15.169",
"versionType": "semver"
},
{
"lessThan": "6.1.115",
"status": "affected",
"version": "6.1.114",
"versionType": "semver"
},
{
"lessThan": "6.6.59",
"status": "affected",
"version": "6.6.58",
"versionType": "semver"
},
{
"lessThan": "6.11.6",
"status": "affected",
"version": "6.11.5",
"versionType": "semver"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.229",
"versionStartIncluding": "5.10.228",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.170",
"versionStartIncluding": "5.15.169",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.115",
"versionStartIncluding": "6.1.114",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.59",
"versionStartIncluding": "6.6.58",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.6",
"versionStartIncluding": "6.11.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nposix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()\n\nIf get_clock_desc() succeeds, it calls fget() for the clockid\u0027s fd,\nand get the clk-\u003erwsem read lock, so the error path should release\nthe lock to make the lock balance and fput the clockid\u0027s fd to make\nthe refcount balance and release the fd related resource.\n\nHowever the below commit left the error path locked behind resulting in\nunbalanced locking. Check timespec64_valid_strict() before\nget_clock_desc() to fix it, because the \"ts\" is not changed\nafter that.\n\n[pabeni@redhat.com: fixed commit message typo]"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:47:33.314Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/d005400262ddaf1ca1666bbcd1acf42fe81d57ce"
},
{
"url": "https://git.kernel.org/stable/c/a8219446b95a859488feaade674d13f9efacfa32"
},
{
"url": "https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943"
},
{
"url": "https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593aa0449af"
},
{
"url": "https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a41506eb794"
},
{
"url": "https://git.kernel.org/stable/c/1ba33b327c3f88a7baee598979d73ab5b44d41cc"
},
{
"url": "https://git.kernel.org/stable/c/b27330128eca25179637c1816d5a72d6cc408c66"
},
{
"url": "https://git.kernel.org/stable/c/6e62807c7fbb3c758d233018caf94dfea9c65dbd"
}
],
"title": "posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-50210",
"datePublished": "2024-11-08T06:08:00.319Z",
"dateReserved": "2024-10-21T19:36:19.970Z",
"dateUpdated": "2026-05-12T12:00:28.952Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
ICSA-24-102-01
Vulnerability from csaf_cisa - Published: 2024-04-09 00:00 - Updated: 2026-05-14 06:00OESA-2024-2535 (CVE-2024-50150)
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: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] </TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)
In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.(CVE-2024-50199)
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: 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: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)
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: 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: 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)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2412.2.0.0307.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2412.2.0.0307.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-2412.2.0.0307.oe2003sp4"
}
],
"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: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: \u0026apos;port0.0\u0026apos; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: \u0026apos;port0.1\u0026apos; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: \u0026apos;port0\u0026apos; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: \u0026apos;port1.0\u0026apos; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: \u0026apos;port1.1\u0026apos; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: \u0026apos;typec\u0026apos; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: \u0026apos;port1\u0026apos; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] \u0026lt;TASK\u0026gt; [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] \u0026lt;/TASK\u0026gt; [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.(CVE-2024-50199)\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: 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: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot; dmsetup create cdata --table \u0026quot;0 65536 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 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot; dmsetup reload cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot; dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 \u0026gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)\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: 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: 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)",
"id": "OESA-2024-2535",
"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-2535"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50199"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50278"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50287"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50302"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53104"
}
],
"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-50150",
"CVE-2024-50199",
"CVE-2024-50210",
"CVE-2024-50267",
"CVE-2024-50278",
"CVE-2024-50287",
"CVE-2024-50302",
"CVE-2024-53104"
]
}
OESA-2024-2536 (CVE-2024-47713)
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: 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: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via <ptr> = val. The .arg_size has been initialized reflecting the actual sizeof(<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write <ptr> = val.(CVE-2024-49861)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)
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: 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: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing.(CVE-2024-50127)
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: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)(CVE-2024-50201)
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: 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: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)
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: 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)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"python3-perf-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.105.0.186.oe2203sp1.src.rpm"
],
"x86_64": [
"kernel-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-136.105.0.186.oe2203sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-136.105.0.186.oe2203sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\n\nSecurity Fix(es):\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta-\u0026gt;raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it\u0026apos;s okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *\u0026lt;ptr\u0026gt; = val. The .arg*_size has been initialized reflecting the actual sizeof(*\u0026lt;ptr\u0026gt;). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *\u0026lt;ptr\u0026gt; = val.(CVE-2024-49861)\n\nIn the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why \u0026amp; how] Change the order of the pipe_ctx-\u0026gt;plane_state check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)\n\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)\n\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)\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In \u0026apos;taprio_change()\u0026apos;, \u0026apos;admin\u0026apos; pointer may become dangling due to sched switch / removal caused by \u0026apos;advance_sched()\u0026apos;, and critical section protected by \u0026apos;q-\u0026gt;current_entry_lock\u0026apos; is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer \u0026apos;rcu_replace_pointer()\u0026apos; over \u0026apos;rcu_assign_pointer()\u0026apos; to update \u0026apos;admin\u0026apos; immediately before an attempt to schedule freeing.(CVE-2024-50127)\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder-\u0026gt;possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\u0026quot;drm: Validate encoder-\u0026gt;possible_clones\u0026quot;). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)(CVE-2024-50201)\n\nIn the Linux kernel, the following vulnerability has been resolved: posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() If get_clock_desc() succeeds, it calls fget() for the clockid\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)\n\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)\n\nIn the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot; dmsetup create cdata --table \u0026quot;0 65536 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 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot; dmsetup reload cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot; dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 \u0026gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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)\n\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-2536",
"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-2536"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47713"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49906"
},
{
"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-50103"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50127"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50134"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50267"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50278"
},
{
"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-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-47713",
"CVE-2024-49861",
"CVE-2024-49906",
"CVE-2024-49923",
"CVE-2024-49977",
"CVE-2024-50103",
"CVE-2024-50127",
"CVE-2024-50134",
"CVE-2024-50201",
"CVE-2024-50210",
"CVE-2024-50267",
"CVE-2024-50278",
"CVE-2024-50290",
"CVE-2024-50292",
"CVE-2024-50301",
"CVE-2024-50302",
"CVE-2024-53104",
"CVE-2024-53110",
"CVE-2024-53112",
"CVE-2024-53125",
"CVE-2024-53130"
]
}
OESA-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)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"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-2554 (CVE-2022-50306)
Vulnerability from osv_openeuler – Published: 2025-10-31 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential out of bound read in ext4_fc_replay_scan()
For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.(CVE-2022-50306)
A use-after-free vulnerability in the Linux kernel s netfilter: nf_tables component can be exploited to achieve local privilege escalation.Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.(CVE-2023-4244)
In the Linux kernel, the following vulnerability has been resolved:
HID: multitouch: Correct devm device reference for hidinput input_dev name
Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management.
Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.(CVE-2023-53454)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix deletion race condition
System crash when using debug kernel due to link list corruption. The cause of the link list corruption is due to session deletion was allowed to queue up twice. Here's the internal trace that show the same port was allowed to double queue for deletion on different cpu.
20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1
Move the clearing/setting of deleted flag lock.(CVE-2023-53615)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix possible desc_ptr out-of-bounds accesses
Sanitize possible desc_ptr out-of-bounds accesses in ses_enclosure_data_process().(CVE-2023-53675)
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix a potential data corruption
We must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list. Add a call that mirrors the effect of nfs_cancel_remove_inode() for O_DIRECT.(CVE-2023-53711)
In the Linux kernel, the following vulnerability has been resolved: md: raid1: fix potential OOB in raid1_remove_disk(). If rddev->raid_disk is greater than mddev->raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows: 1) commit d17f744e883b ("md-raid10: fix KASAN warning") 2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk"). Fix this bug by checking whether the "number" variable is valid.(CVE-2023-53722)
In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)
In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.pabeni@redhat.com: fixed commit message typo
In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)
In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field &msg->msg[msg->curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 drm_display_helper
In the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st->ts_input, however, the err label can be reached before theallocated iio_dev is stored to st->ts_input. Thus callinput_free_device() on input instead of st->ts_input.(CVE-2024-57904)
In the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)
In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)
In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.kwilczynski: commit log
In the Linux kernel, the following vulnerability has been resolved:
bpf: consider that tail calls invalidate packet pointers
Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.
Making the change in bpf_helper_changes_pkt_data() automatically makes use of check_cfg() logic that computes 'changes_pkt_data' effect for global sub-programs, such that the following program could be rejected:
int tail_call(struct __sk_buff *sk)
{
bpf_tail_call_static(sk, &jmp_table, 0);
return 0;
}
SEC("tc")
int not_safe(struct __sk_buff *sk)
{
int *p = (void *)(long)sk->data;
... make p valid ...
tail_call(sk);
*p = 42; /* this is unsafe */
...
}
The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)
In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)
In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix oops when unload drivers paralleling
When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops.
But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock.
To fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)
In the Linux kernel, the following vulnerability has been resolved:
sctp: detect and prevent references to a freed transport in sendmsg
sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent.
There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf().
This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read.
This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").
Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process.
If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send.
The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).(CVE-2025-23142)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: drr: Fix double list add in class with netem as child qdisc
As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Flush gso_skb list too during ->change()
Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.
This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.(CVE-2025-37992)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.
Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.
In the case where the unconfirmed client is expiring, just fail and return the result from get_client_locked().(CVE-2025-38724)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"perf-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.189.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-287.0.0.189.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"perf-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.189.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-287.0.0.189.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential out of bound read in ext4_fc_replay_scan()\n\nFor scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain\nspace less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read\nwhen mounting corrupt file system image.\nADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this\nthree tags will read data during scan, tag length couldn\u0026apos;t less than data length\nwhich will read.(CVE-2022-50306)\n\nA use-after-free vulnerability in the Linux kernel s netfilter: nf_tables component can be exploited to achieve local privilege escalation.Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.(CVE-2023-4244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: multitouch: Correct devm device reference for hidinput input_dev name\n\nReference the HID device rather than the input device for the devm\nallocation of the input_dev name. Referencing the input_dev would lead to a\nuse-after-free when the input_dev was unregistered and subsequently fires a\nuevent that depends on the name. At the point of firing the uevent, the\nname would be freed by devres management.\n\nUse devm_kasprintf to simplify the logic for allocating memory and\nformatting the input_dev name string.(CVE-2023-53454)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix deletion race condition\n\nSystem crash when using debug kernel due to link list corruption. The cause\nof the link list corruption is due to session deletion was allowed to queue\nup twice. Here\u0026apos;s the internal trace that show the same port was allowed to\ndouble queue for deletion on different cpu.\n\n20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\n20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1\n\nMove the clearing/setting of deleted flag lock.(CVE-2023-53615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix possible desc_ptr out-of-bounds accesses\n\nSanitize possible desc_ptr out-of-bounds accesses in\nses_enclosure_data_process().(CVE-2023-53675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a potential data corruption\n\nWe must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list.\nAdd a call that mirrors the effect of nfs_cancel_remove_inode() for O_DIRECT.(CVE-2023-53711)\n\nIn the Linux kernel, the following vulnerability has been resolved: md: raid1: fix potential OOB in raid1_remove_disk(). If rddev-\u0026gt;raid_disk is greater than mddev-\u0026gt;raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows: 1) commit d17f744e883b (\u0026quot;md-raid10: fix KASAN warning\u0026quot;) 2) commit 1ebc2cec0b7d (\u0026quot;dm raid: fix KASAN warning in raid5_remove_disk\u0026quot;). Fix this bug by checking whether the \u0026quot;number\u0026quot; variable is valid.(CVE-2023-53722)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig-\u0026gt;posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig-\u0026gt;posix_timer_id \u0026lt; 0) start = sig-\u0026gt;posix_timer_id; sig-\u0026gt;posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig-\u0026gt;posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk-\u0026gt;rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.[pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\n\nIn the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: \u0026lt;TASK\u0026gt; ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field \u0026amp;msg-\u0026gt;msg[msg-\u0026gt;curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper](CVE-2024-56616)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st-\u0026gt;ts_input, however, the err label can be reached before theallocated iio_dev is stored to st-\u0026gt;ts_input. Thus callinput_free_device() on input instead of st-\u0026gt;ts_input.(CVE-2024-57904)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)\n\nIn the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link-\u0026gt;downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log](CVE-2024-58093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: consider that tail calls invalidate packet pointers\n\nTail-called programs could execute any of the helpers that invalidate\npacket pointers. Hence, conservatively assume that each tail call\ninvalidates packet pointers.\n\nMaking the change in bpf_helper_changes_pkt_data() automatically makes\nuse of check_cfg() logic that computes \u0026apos;changes_pkt_data\u0026apos; effect for\nglobal sub-programs, such that the following program could be\nrejected:\n\n int tail_call(struct __sk_buff *sk)\n {\n \tbpf_tail_call_static(sk, \u0026amp;jmp_table, 0);\n \treturn 0;\n }\n\n SEC(\u0026quot;tc\u0026quot;)\n int not_safe(struct __sk_buff *sk)\n {\n \tint *p = (void *)(long)sk-\u0026gt;data;\n \t... make p valid ...\n \ttail_call(sk);\n \t*p = 42; /* this is unsafe */\n \t...\n }\n\nThe tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that\ncan invalidate packet pointers. Otherwise, it can\u0026apos;t be freplaced with\ntailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)\n\nIn the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)\n\nIn the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix oops when unload drivers paralleling\n\nWhen unload hclge driver, it tries to disable sriov first for each\nae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at\nthe time, because it removes all the ae_dev nodes, and it may cause\noops.\n\nBut we can\u0026apos;t simply use hnae3_common_lock for this. Because in the\nprocess flow of pci_disable_sriov(), it will trigger the remove flow\nof VF, which will also take hnae3_common_lock.\n\nTo fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere\u0026apos;s a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as \u0026quot;dead\u0026quot;. In order to do this,\nthe patch restores the \u0026quot;dead\u0026quot; bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e (\u0026quot;sctp: remove the dead field of sctp_transport\u0026quot;).\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).(CVE-2025-23142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too\n\nSimilarly to the previous patch, we need to safe guard hfsc_dequeue()\ntoo. But for this one, we don\u0026apos;t have a reliable reproducer.(CVE-2025-37823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: drr: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of drr, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether the\nclass was already added to the active_list (cl_is_active) before adding\nto the list to cover for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Flush gso_skb list too during -\u0026gt;change()\n\nPreviously, when reducing a qdisc\u0026apos;s limit via the -\u0026gt;change() operation, only\nthe main skb queue was trimmed, potentially leaving packets in the gso_skb\nlist. This could result in NULL pointer dereference when we only check\nsch-\u0026gt;limit against sch-\u0026gt;q.qlen.\n\nThis patch introduces a new helper, qdisc_dequeue_internal(), which ensures\nboth the gso_skb list and the main queue are properly flushed when trimming\nexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)\nare updated to use this helper in their -\u0026gt;change() routines.(CVE-2025-37992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()\n\nLei Lu recently reported that nfsd4_setclientid_confirm() did not check\nthe return value from get_client_locked(). a SETCLIENTID_CONFIRM could\nrace with a confirmed client expiring and fail to get a reference. That\ncould later lead to a UAF.\n\nFix this by getting a reference early in the case where there is an\nextant confirmed client. If that fails then treat it as if there were no\nconfirmed client found at all.\n\nIn the case where the unconfirmed client is expiring, just fail and\nreturn the result from get_client_locked().(CVE-2025-38724)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)",
"id": "OESA-2025-2554",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2554"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50306"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4244"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53454"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53675"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53722"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50306",
"CVE-2023-4244",
"CVE-2023-53454",
"CVE-2023-53615",
"CVE-2023-53675",
"CVE-2023-53711",
"CVE-2023-53722",
"CVE-2023-53728",
"CVE-2024-50210",
"CVE-2024-53168",
"CVE-2024-53214",
"CVE-2024-56602",
"CVE-2024-56616",
"CVE-2024-57904",
"CVE-2024-57906",
"CVE-2024-57931",
"CVE-2024-58052",
"CVE-2024-58093",
"CVE-2024-58237",
"CVE-2025-21665",
"CVE-2025-21772",
"CVE-2025-21802",
"CVE-2025-23142",
"CVE-2025-37823",
"CVE-2025-37915",
"CVE-2025-37992",
"CVE-2025-38724",
"CVE-2025-39898",
"CVE-2025-39971",
"CVE-2025-39998"
]
}
OESA-2025-2555 (CVE-2022-50306)
Vulnerability from osv_openeuler – Published: 2025-10-31 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential out of bound read in ext4_fc_replay_scan()
For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.(CVE-2022-50306)
In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)
In the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk->rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.pabeni@redhat.com: fixed commit message typo
In the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK>Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device->pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)
In the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)
In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field &msg->msg[msg->curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 drm_display_helper
In the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st->ts_input, however, the err label can be reached before theallocated iio_dev is stored to st->ts_input. Thus callinput_free_device() on input instead of st->ts_input.(CVE-2024-57904)
In the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)
In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)
In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)
In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.kwilczynski: commit log
In the Linux kernel, the following vulnerability has been resolved:
bpf: consider that tail calls invalidate packet pointers
Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.
Making the change in bpf_helper_changes_pkt_data() automatically makes use of check_cfg() logic that computes 'changes_pkt_data' effect for global sub-programs, such that the following program could be rejected:
int tail_call(struct __sk_buff *sk)
{
bpf_tail_call_static(sk, &jmp_table, 0);
return 0;
}
SEC("tc")
int not_safe(struct __sk_buff *sk)
{
int *p = (void *)(long)sk->data;
... make p valid ...
tail_call(sk);
*p = 42; /* this is unsafe */
...
}
The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)
In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)
In the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix oops when unload drivers paralleling
When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops.
But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock.
To fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)
In the Linux kernel, the following vulnerability has been resolved:
sctp: detect and prevent references to a freed transport in sendmsg
sctp_sendmsg() re-uses associations and transports when possible by doing a lookup based on the socket endpoint and the message destination address, and then sctp_sendmsg_to_asoc() sets the selected transport in all the message chunks to be sent.
There's a possible race condition if another thread triggers the removal of that selected transport, for instance, by explicitly unbinding an address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have been set up and before the message is sent. This can happen if the send buffer is full, during the period when the sender thread temporarily releases the socket lock in sctp_wait_for_sndbuf().
This causes the access to the transport data in sctp_outq_select_transport(), when the association outqueue is flushed, to result in a use-after-free read.
This change avoids this scenario by having sctp_transport_free() signal the freeing of the transport, tagging it as "dead". In order to do this, the patch restores the "dead" bit in struct sctp_transport, which was removed in commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").
Then, in the scenario where the sender thread has released the socket lock in sctp_wait_for_sndbuf(), the bit is checked again after re-acquiring the socket lock to detect the deletion. This is done while holding a reference to the transport to prevent it from being freed in the process.
If the transport was deleted while the socket lock was relinquished, sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the send.
The bug was found by a private syzbot instance (see the error report [1] and the C reproducer that triggers it [2]).(CVE-2025-23142)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: drr: Fix double list add in class with netem as child qdisc
As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of drr, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.
In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before adding to the list to cover for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: Flush gso_skb list too during ->change()
Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.
This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.(CVE-2025-37992)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.
Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.
In the case where the unconfirmed client is expiring, just fail and return the result from get_client_locked().(CVE-2025-38724)
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)
In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)
In the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"perf-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-287.0.0.190.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"perf-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-287.0.0.190.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-287.0.0.190.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential out of bound read in ext4_fc_replay_scan()\n\nFor scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain\nspace less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read\nwhen mounting corrupt file system image.\nADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this\nthree tags will read data during scan, tag length couldn\u0026apos;t less than data length\nwhich will read.(CVE-2022-50306)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that s racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig-\u0026gt;posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig-\u0026gt;posix_timer_id \u0026lt; 0) start = sig-\u0026gt;posix_timer_id; sig-\u0026gt;posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig-\u0026gt;posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.(CVE-2023-53728)\n\nIn the Linux kernel, the following vulnerability has been resolved:posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()If get_clock_desc() succeeds, it calls fget() for the clockid s fd,and get the clk-\u0026gt;rwsem read lock, so the error path should releasethe lock to make the lock balance and fput the clockid s fd to makethe refcount balance and release the fd related resource.However the below commit left the error path locked behind resulting inunbalanced locking. Check timespec64_valid_strict() beforeget_clock_desc() to fix it, because the ts is not changedafter that.[pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\n\nIn the Linux kernel, the following vulnerability has been resolved:sunrpc: fix one UAF issue caused by sunrpc kernel tcp socketBUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0Read of size 1 at addr ffff888111f322cd by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 \u0026lt;/IRQ\u0026gt; \u0026lt;TASK\u0026gt; asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:default_idle+0xf/0x20Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590fRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835dR10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 \u0026lt;/TASK\u0026gt;Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30Reproduction script:mkdir -p /mnt/nfssharemkdir -p /mnt/nfs/netns_1mkfs.ext4 /dev/sdbmount /dev/sdb /mnt/nfssharesystemctl restart nfs-serverchmod 777 /mnt/nfsshareexportfs -i -o rw,no_root_squash *:/mnt/nfsshareip netns add netns_1ip link add name veth_1_peer type veth peer veth_1ifconfig veth_1_peer 11.11.0.254 upip link set veth_1 netns netns_1ip netns exec netns_1 ifconfig veth_1 11.11.0.1ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp --tcp-flags FIN FIN -j DROP(note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.)ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1ip netns del netns_1The reason here is that the tcp socket in netns_1 (nfs side) has beenshutdown and closed (done in xs_destroy), but the FIN message (with ack)is discarded, and the nfsd side keeps sending retransmission messages.As a result, when the tcp sock in netns_1 processes the received message,it sends the message (FIN message) in the sending queue, and the tcp timeris re-established. When the network namespace is deleted, the net structureaccessed by tcp s timer handler function causes problems.To fix this problem, let s hold netns refcnt for the tcp kernel socket asdone in other modules. This is an ugly hack which can easily be backportedto earlier kernels. A proper fix which cleans up the interfaces willfollow, but may not be so easy to backport.(CVE-2024-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:vfio/pci: Properly hide first-in-list PCIe extended capabilityThere are cases where a PCIe extended capability should be hidden fromthe user. For example, an unknown capability (i.e., capability with IDgreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionallychosen to be hidden from the user.Hiding a capability is done by virtualizing and modifying the NextCapability Offset field of the previous capability so it points to thecapability after the one that should be hidden.The special case where the first capability in the list should be hiddenis handled differently because there is no previous capability that canbe modified. In this case, the capability ID and version are zeroedwhile leaving the next pointer intact. This hides the capability andleaves an anchor for the rest of the capability list.However, today, hiding the first capability in the list is not doneproperly if the capability is unknown, as structvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID duringinitialization but the capability ID is not properly checked later whenused in vfio_config_do_rw(). This leads to the following warning [1] andto an out-of-bounds access to ecap_perms array.Fix it by checking cap_id in vfio_config_do_rw(), and if it is greaterthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for directread only access instead of the ecap_perms array.Note that this is safe since the above is the only case where cap_id canexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, whichare already checked before).[1]WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1(snip)Call Trace: \u0026lt;TASK\u0026gt; ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If ieee802154_create() fails later, the allocated sk object isfreed, but the dangling pointer remains in the provided sock object, whichmay allow use-after-free.Clear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type u8 [48] Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field \u0026amp;msg-\u0026gt;msg[msg-\u0026gt;curlen] at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper](CVE-2024-56616)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: at91: call input_free_device() on allocated iio_devCurrent implementation of at91_ts_register() calls input_free_deivce()on st-\u0026gt;ts_input, however, the err label can be reached before theallocated iio_dev is stored to st-\u0026gt;ts_input. Thus callinput_free_device() on input instead of st-\u0026gt;ts_input.(CVE-2024-57904)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: adc: ti-ads8688: fix information leak in triggered bufferThe buffer local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57906)\n\nIn the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.(CVE-2024-57931)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.(CVE-2024-58052)\n\nIn the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ( PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free ), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link-\u0026gt;downstream would point to free d memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log](CVE-2024-58093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: consider that tail calls invalidate packet pointers\n\nTail-called programs could execute any of the helpers that invalidate\npacket pointers. Hence, conservatively assume that each tail call\ninvalidates packet pointers.\n\nMaking the change in bpf_helper_changes_pkt_data() automatically makes\nuse of check_cfg() logic that computes \u0026apos;changes_pkt_data\u0026apos; effect for\nglobal sub-programs, such that the following program could be\nrejected:\n\n int tail_call(struct __sk_buff *sk)\n {\n \tbpf_tail_call_static(sk, \u0026amp;jmp_table, 0);\n \treturn 0;\n }\n\n SEC(\u0026quot;tc\u0026quot;)\n int not_safe(struct __sk_buff *sk)\n {\n \tint *p = (void *)(long)sk-\u0026gt;data;\n \t... make p valid ...\n \ttail_call(sk);\n \t*p = 42; /* this is unsafe */\n \t...\n }\n\nThe tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that\ncan invalidate packet pointers. Otherwise, it can\u0026apos;t be freplaced with\ntailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)\n\nIn the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.(CVE-2025-21665)\n\nIn the Linux kernel, the following vulnerability has been resolved:partitions: mac: fix handling of bogus partition tableFix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix oops when unload drivers paralleling\n\nWhen unload hclge driver, it tries to disable sriov first for each\nae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at\nthe time, because it removes all the ae_dev nodes, and it may cause\noops.\n\nBut we can\u0026apos;t simply use hnae3_common_lock for this. Because in the\nprocess flow of pci_disable_sriov(), it will trigger the remove flow\nof VF, which will also take hnae3_common_lock.\n\nTo fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere\u0026apos;s a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as \u0026quot;dead\u0026quot;. In order to do this,\nthe patch restores the \u0026quot;dead\u0026quot; bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e (\u0026quot;sctp: remove the dead field of sctp_transport\u0026quot;).\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).(CVE-2025-23142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too\n\nSimilarly to the previous patch, we need to safe guard hfsc_dequeue()\ntoo. But for this one, we don\u0026apos;t have a reliable reproducer.(CVE-2025-37823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: drr: Fix double list add in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], there are use cases where a netem\nchild qdisc will make the parent qdisc\u0026apos;s enqueue callback reentrant.\nIn the case of drr, there won\u0026apos;t be a UAF, but the code will add the same\nclassifier to the list twice, which will cause memory corruption.\n\nIn addition to checking for qlen being zero, this patch checks whether the\nclass was already added to the active_list (cl_is_active) before adding\nto the list to cover for the reentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: Flush gso_skb list too during -\u0026gt;change()\n\nPreviously, when reducing a qdisc\u0026apos;s limit via the -\u0026gt;change() operation, only\nthe main skb queue was trimmed, potentially leaving packets in the gso_skb\nlist. This could result in NULL pointer dereference when we only check\nsch-\u0026gt;limit against sch-\u0026gt;q.qlen.\n\nThis patch introduces a new helper, qdisc_dequeue_internal(), which ensures\nboth the gso_skb list and the main queue are properly flushed when trimming\nexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)\nare updated to use this helper in their -\u0026gt;change() routines.(CVE-2025-37992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()\n\nLei Lu recently reported that nfsd4_setclientid_confirm() did not check\nthe return value from get_client_locked(). a SETCLIENTID_CONFIRM could\nrace with a confirmed client expiring and fail to get a reference. That\ncould later lead to a UAF.\n\nFix this by getting a reference early in the case where there is an\nextant confirmed client. If that fails then treat it as if there were no\nconfirmed client found at all.\n\nIn the case where the unconfirmed client is expiring, just fail and\nreturn the result from get_client_locked().(CVE-2025-38724)\n\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-39898)\n\nIn the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf-\u0026gt;ch[idx] in i40e_vc_config_queues_msg().(CVE-2025-39971)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer \u0026quot;buf\u0026quot; without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)",
"id": "OESA-2025-2555",
"modified": "2026-08-06T11:09:38Z",
"published": "2025-10-31T11:09:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2555"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50306"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53168"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53214"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56602"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57906"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58093"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58237"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21665"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21772"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37992"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38724"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39971"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39998"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50306",
"CVE-2023-53728",
"CVE-2024-50210",
"CVE-2024-53168",
"CVE-2024-53214",
"CVE-2024-56602",
"CVE-2024-56616",
"CVE-2024-57904",
"CVE-2024-57906",
"CVE-2024-57931",
"CVE-2024-58052",
"CVE-2024-58093",
"CVE-2024-58237",
"CVE-2025-21665",
"CVE-2025-21772",
"CVE-2025-21802",
"CVE-2025-23142",
"CVE-2025-37823",
"CVE-2025-37915",
"CVE-2025-37992",
"CVE-2025-38724",
"CVE-2025-39898",
"CVE-2025-39971",
"CVE-2025-39998"
]
}
OPENSUSE-SU-2024:14500-1
Vulnerability from csaf_opensuse - Published: 2024-11-15 00:00 - Updated: 2026-09-20 21:21OPENSUSE-SU-2025:14705-1
Vulnerability from csaf_opensuse - Published: 2025-01-28 00:00 - Updated: 2026-09-20 21:25SSA-265688
Vulnerability from csaf_siemens - Published: 2024-04-09 00:00 - Updated: 2026-05-12 00:00SUSE-SU-2024:4314-1
Vulnerability from csaf_suse - Published: 2024-12-13 15:23 - Updated: 2026-09-20 17:14Sightings
| 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.