Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-35808 (GCVE-0-2024-35808)
Vulnerability from cvelistv5 – Published: 2024-05-17 13:23 – Updated: 2026-08-05 11:30| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
be83651f0050ca8621d58d35dad558e9c45cb18f , < 347dcdc15a1706f61aa545ae498ededdf31aeebc
(git)
Affected: be83651f0050ca8621d58d35dad558e9c45cb18f , < 9e59b8d76ff511505eb0dd1478329f09e0f04669 (git) Affected: be83651f0050ca8621d58d35dad558e9c45cb18f , < cd32b27a66db8776d8b8e82ec7d7dde97a8693b0 (git) |
guessed | |
| Linux | Linux |
Affected:
3.10
Unaffected: 0 , < 3.10 (semver) Unaffected: 6.7.12 , ≤ 6.7.* (semver) Unaffected: 6.8.3 , ≤ 6.8.* (semver) Unaffected: 6.9 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-35808",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T14:17:42.560355Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-04T17:34:02.913Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-02T03:21:47.484Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "347dcdc15a1706f61aa545ae498ededdf31aeebc",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
},
{
"lessThan": "9e59b8d76ff511505eb0dd1478329f09e0f04669",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
},
{
"lessThan": "cd32b27a66db8776d8b8e82ec7d7dde97a8693b0",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"lessThan": "3.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7.12",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "3.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/dm-raid: don\u0027t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0027reconfig_mutex\u0027, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0027reconfig_mutex\u0027.\n\nHowever, hold \u0027reconfig_mutex\u0027 here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\"md: refactor\nidle/frozen_sync_thread() to fix deadlock\").\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable `raid_message()` handler is reached only through the local `DM_TARGET_MSG` ioctl on /dev/mapper/control (`ctl_ioctl` \u2192 `target_message` \u2192 `ti-\u003etype-\u003emessage`). No remote or adjacent network path exists.\nAC:L - The attacker controls both sides of the race \u2014 it can start a sync/reshape with a `check`/`repair`/`resync` message and then issue concurrent `idle`/`frozen` messages from multiple threads, so two contexts enter `md_reap_sync_thread()` simultaneously; dm-raid is a standard distro module, so no rare configuration is needed.\nPR:L - The device-mapper control ioctl is gated by CAP_SYS_ADMIN, but this is delegated capability rather than exclusive host root in practice \u2014 privileged containers, storage-management daemons and LVM helper services hold it \u2014 and kernel-CNA scoring consistently treats dm-ioctl-reachable defects as low-privilege local attacks.\nUI:N - The attacker performs every step itself (create/activate the dm-raid target, start the sync thread, issue the racing messages); no action by another user or administrator is required.\nS:U - The corruption is confined to kernel memory and on-disk RAID metadata managed by the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The unlocked reap yields a use-after-free/double-free of `struct md_thread` plus an unsynchronized walk of the `mddev-\u003edisks` rdev list, and reclaiming the freed slab object gives an attacker-controlled read primitive over kernel memory.\nI:H - The double `kfree()`/UAF is a classic heap-corruption primitive exploitable for arbitrary write and control-flow hijack, and additionally `md_update_sb()` and `pers-\u003efinish_reshape()` run concurrently with the md thread, writing inconsistent RAID superblocks and mutating array geometry mid-reshape.\nA:H - Double-free/UAF of the sync thread reliably produces slab corruption, oops, and kernel panic, and the unsynchronized recovery-flag manipulation can wedge the sync-thread state machine into the deadlock/hang class the commit series explicitly addresses."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:30:03.700Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc"
},
{
"url": "https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669"
},
{
"url": "https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0"
}
],
"title": "md/dm-raid: don\u0027t call md_reap_sync_thread() directly",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-35808",
"datePublished": "2024-05-17T13:23:15.515Z",
"dateReserved": "2024-05-17T12:19:12.342Z",
"dateUpdated": "2026-08-05T11:30:03.700Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-35808",
"date": "2026-09-27",
"epss": "0.0018",
"percentile": "0.06844"
},
"microsoft_vex": {
"current_release_date": "2026-09-24T02:22:41.000Z",
"cve": "CVE-2024-35808",
"id": "msrc_CVE-2024-35808",
"initial_release_date": "2024-09-11T00:00:00.000Z",
"product_status:fixed": "2",
"product_status:known_affected": "23",
"product_status:under_investigation": "4",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "md/dm-raid: don\u0027t call md_reap_sync_thread() directly",
"url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-35808.json",
"version": "21"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "347dcdc15a1706f61aa545ae498ededdf31aeebc",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
},
{
"lessThan": "9e59b8d76ff511505eb0dd1478329f09e0f04669",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
},
{
"lessThan": "cd32b27a66db8776d8b8e82ec7d7dde97a8693b0",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"lessThan": "3.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8B53C24B-2D46-4DC6-85C6-628182B5EA0E",
"versionEndExcluding": "6.7.12",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4C59BBC3-6495-4A77-9C82-55EC7CDF5E02",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "6.8",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/dm-raid: don\u0027t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0027reconfig_mutex\u0027, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0027reconfig_mutex\u0027.\n\nHowever, hold \u0027reconfig_mutex\u0027 here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\"md: refactor\nidle/frozen_sync_thread() to fix deadlock\").\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did."
},
{
"lang": "es",
"value": " En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/dm-raid: no llame a md_reap_sync_thread() directamente Actualmente, se llama a md_reap_sync_thread() desde raid_message() directamente sin mantener presionado \u0027reconfig_mutex\u0027, esto definitivamente no es seguro porque md_reap_sync_thread( ) puede cambiar muchos campos protegidos por \u0027reconfig_mutex\u0027. Sin embargo, mantener \u0027reconfig_mutex\u0027 aqu\u00ed sigue siendo problem\u00e1tico porque esto causar\u00e1 un punto muerto, por ejemplo, confirme 130443d60b1b (\"md: refactor idle/frozen_sync_thread() to fix deadlock\"). Solucione este problema usando stop_sync_thread() para cancelar el registro de sync_thread, como lo hizo md/raid."
}
],
"id": "CVE-2024-35808",
"lastModified": "2026-08-04T11:17:54.723",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 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"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-35808",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T14:17:42.560355Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-05-17T14:15:14.503",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-08-04T19:07:19+00:00",
"cve": "CVE-2024-35808",
"id": "CVE-2024-35808",
"initial_release_date": "2024-05-17T00:00:00+00:00",
"product_status:fixed": "280",
"product_status:known_affected": "112",
"product_status:known_not_affected": "8",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: md/dm-raid: don\u0026#39;t call md_reap_sync_thread() directly",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-35808.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T03:21:47.484Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2024-35808",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-05-24T14:17:42.560355Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-05-24T14:17:48.212Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "347dcdc15a1706f61aa545ae498ededdf31aeebc",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
},
{
"lessThan": "9e59b8d76ff511505eb0dd1478329f09e0f04669",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
},
{
"lessThan": "cd32b27a66db8776d8b8e82ec7d7dde97a8693b0",
"status": "affected",
"version": "be83651f0050ca8621d58d35dad558e9c45cb18f",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/md/dm-raid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.10"
},
{
"lessThan": "3.10",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.7.*",
"status": "unaffected",
"version": "6.7.12",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.8.*",
"status": "unaffected",
"version": "6.8.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.9",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.7.12",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.8.3",
"versionStartIncluding": "3.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.9",
"versionStartIncluding": "3.10",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/dm-raid: don\u0027t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0027reconfig_mutex\u0027, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0027reconfig_mutex\u0027.\n\nHowever, hold \u0027reconfig_mutex\u0027 here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\"md: refactor\nidle/frozen_sync_thread() to fix deadlock\").\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable `raid_message()` handler is reached only through the local `DM_TARGET_MSG` ioctl on /dev/mapper/control (`ctl_ioctl` \u2192 `target_message` \u2192 `ti-\u003etype-\u003emessage`). No remote or adjacent network path exists.\nAC:L - The attacker controls both sides of the race \u2014 it can start a sync/reshape with a `check`/`repair`/`resync` message and then issue concurrent `idle`/`frozen` messages from multiple threads, so two contexts enter `md_reap_sync_thread()` simultaneously; dm-raid is a standard distro module, so no rare configuration is needed.\nPR:L - The device-mapper control ioctl is gated by CAP_SYS_ADMIN, but this is delegated capability rather than exclusive host root in practice \u2014 privileged containers, storage-management daemons and LVM helper services hold it \u2014 and kernel-CNA scoring consistently treats dm-ioctl-reachable defects as low-privilege local attacks.\nUI:N - The attacker performs every step itself (create/activate the dm-raid target, start the sync thread, issue the racing messages); no action by another user or administrator is required.\nS:U - The corruption is confined to kernel memory and on-disk RAID metadata managed by the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The unlocked reap yields a use-after-free/double-free of `struct md_thread` plus an unsynchronized walk of the `mddev-\u003edisks` rdev list, and reclaiming the freed slab object gives an attacker-controlled read primitive over kernel memory.\nI:H - The double `kfree()`/UAF is a classic heap-corruption primitive exploitable for arbitrary write and control-flow hijack, and additionally `md_update_sb()` and `pers-\u003efinish_reshape()` run concurrently with the md thread, writing inconsistent RAID superblocks and mutating array geometry mid-reshape.\nA:H - Double-free/UAF of the sync thread reliably produces slab corruption, oops, and kernel panic, and the unsynchronized recovery-flag manipulation can wedge the sync-thread state machine into the deadlock/hang class the commit series explicitly addresses."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:30:03.700Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/347dcdc15a1706f61aa545ae498ededdf31aeebc"
},
{
"url": "https://git.kernel.org/stable/c/9e59b8d76ff511505eb0dd1478329f09e0f04669"
},
{
"url": "https://git.kernel.org/stable/c/cd32b27a66db8776d8b8e82ec7d7dde97a8693b0"
}
],
"title": "md/dm-raid: don\u0027t call md_reap_sync_thread() directly",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-35808",
"datePublished": "2024-05-17T13:23:15.515Z",
"dateReserved": "2024-05-17T12:19:12.342Z",
"dateUpdated": "2026-08-05T11:30:03.700Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
OESA-2024-1694 (CVE-2021-47265)
Vulnerability from osv_openeuler – Published: 2024-06-07 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
RDMA: Verify port when creating flow rule
Validate port value provided by the user and with that remove no longer needed validation by the driver. The missing check in the mlx5_ib driver could cause to the below oops.
Call trace: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 el0_svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)
In the Linux kernel, the following vulnerability has been resolved:
mISDN: fix possible use-after-free in HFC_cleanup()
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.
Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47356)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure tx skbs always have the MPTCP ext
Due to signed/unsigned comparison, the expression:
info->size_goal - skb->len > 0
evaluates to true when the size goal is smaller than the skb size. That results in lack of tx cache refill, so that the skb allocated by the core TCP code lacks the required MPTCP skb extensions.
Due to the above, syzbot is able to trigger the following WARN_ON():
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Modules linked in: CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9 RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216 RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000 RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003 RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280 R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0 FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547 mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003 release_sock+0xb4/0x1b0 net/core/sock.c:3206 sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145 mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749 inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 sock_write_iter+0x2a0/0x3e0 net/socket.c:1057 call_write_iter include/linux/fs.h:2163 [inline] new_sync_write+0x40b/0x640 fs/read_write.c:507 vfs_write+0x7cf/0xae0 fs/read_write.c:594 ksys_write+0x1ee/0x250 fs/read_write.c:647 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9 RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038 R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000
Fix the issue rewriting the relevant expression to avoid sign-related problems - note: size_goal is always >= 0.
Additionally, ensure that the skb in the tx cache always carries the relevant extension.(CVE-2021-47370)
In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi: Fix iscsi_task use after free
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task.
This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix even more out of bound writes from debugfs
CVE-2021-42327 was fixed by:
commit f23750b5b3d98653b31d4469592935ef6364ad67 Author: Thelford Williams <tdwilliamsiv@gmail.com> Date: Wed Oct 13 16:04:13 2021 -0400
drm/amdgpu: fix out of bounds write
but amdgpu_dm_debugfs.c contains more of the same issue so fix the remaining ones.
v2: * Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)
In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives.
There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index.
Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive.
Backporting to older kernel versions seems not necessary.
[1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000000000 -> 0xffffea0004a1d288
Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/af_unix: disable sending io_uring over sockets
File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary.(CVE-2023-52654)
In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.(CVE-2023-52669)
In the Linux kernel, the following vulnerability has been resolved:
riscv: Check if the code to patch lies in the exit section
Otherwise we fall through to vmalloc_to_page() which panics since the address does not lie in the vmalloc region.(CVE-2023-52677)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_powercap_init()
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52696)
In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held.
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).(CVE-2023-52699)
In the Linux kernel, the following vulnerability has been resolved:
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
This went unnoticed until commit:
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state.
After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g.
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __pi_strcmp+0x1c/0x150 | lr : populate_properties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xec/0x108 | show_stack+0x18/0x2c | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | panic+0x13c/0x340 | el1t_64_irq_handler+0x0/0x1c | el1_abort+0x0/0x5c | el1h_64_sync+0x64/0x68 | __pi_strcmp+0x1c/0x150 | unflatten_dt_nodes+0x1e8/0x2d8 | __unflatten_device_tree+0x5c/0x15c | unflatten_device_tree+0x38/0x50 | setup_arch+0x164/0x1e0 | start_kernel+0x64/0x38c | __primary_switched+0xbc/0xc4
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.(CVE-2023-52750)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down (e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show() to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting
[ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference.(CVE-2023-52753)
In the Linux kernel, the following vulnerability has been resolved:
pwm: Fix double shift bug
These enums are passed to set/test_bit(). The set/test_bit() functions take a bit number instead of a shifted value. Passing a shifted value is a double shift bug like doing BIT(BIT(1)). The double shift bug doesn't cause a problem here because we are only checking 0 and 1 but if the value was 5 or above then it can lead to a buffer overflow.(CVE-2023-52756)
In the Linux kernel, the following vulnerability has been resolved:
gfs2: ignore negated quota changes
When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function do_qc can add pending quota changes to a transaction, then later, another call to do_qc can negate those changes, resulting in a net gain of 0. The quota_change information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to do_qc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. Later, when the quota sync code is called, the zero-change qd element is discovered and flagged as an assert warning. If the fs is mounted with errors=panic, the kernel will panic.
This is usually seen when files are truncated and the quota changes are negated by punch_hole/truncate which uses gfs2_quota_hold and gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock and gfs2_quota_unlock which automatically do quota sync.
This patch solves the problem by adding a check to qd_check_sync such that net-zero quota changes already added to the transaction are no longer deemed necessary to be synced, and skipped.
In this case references are taken for the qd and the slot from do_qc so those need to be put. The normal sequence of events for a normal non-zero quota change is as follows:
gfs2_quota_change do_qc qd_hold slot_hold
Later, when the changes are to be synced:
gfs2_quota_sync qd_fish qd_check_sync gets qd ref via lockref_get_not_dead do_sync do_qc(QC_SYNC) qd_put lockref_put_or_lock qd_unlock qd_put lockref_put_or_lock
In the net-zero change case, we add a check to qd_check_sync so it puts the qd and slot references acquired in gfs2_quota_change and skip the unneeded sync.(CVE-2023-52759)
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: protect device queue against concurrent access
In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses.
Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)
In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: Add check for kstrdup() in vcc_probe()
Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.(CVE-2023-52789)
In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: fix use after free in vhost_vdpa_probe()
The put_device() calls vhost_vdpa_release_dev() which calls ida_simple_remove() and frees "v". So this call to ida_simple_remove() is a use after free and a double free.(CVE-2023-52795)
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: add ipvlan_route_v6_outbound() helper
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<f ---truncated---(CVE-2023-52796)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix dfs radar event locking
The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.
Compile tested only.(CVE-2023-52798)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbFindLeaf
Currently while searching for dmtree_t for sufficient free blocks there is an array out of bounds while getting element in tp->dm_stree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied.(CVE-2023-52799)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix htt pktlog locking
The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.
Compile tested only.(CVE-2023-52800)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()
of_match_device() may fail and returns a NULL pointer.
In practice there is no known reasonable way to trigger this, but in case one is added in future, harden the code by adding the check(CVE-2023-52802)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential null pointer derefernce
The amdgpu_ras_get_context may return NULL if device not support ras feature, so add check before using.(CVE-2023-52814)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)
In the Linux kernel, the following vulnerability has been resolved:
drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
In tpg110_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)
In the Linux kernel, the following vulnerability has been resolved:
cpu/hotplug: Don't offline the last non-isolated CPU
If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked().
cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
Thus results in an empty CPU mask which triggers the warning and then the subsequent crash:
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930
Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798
Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU.
Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level".
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate that no data is available.(CVE-2023-52832)
In the Linux kernel, the following vulnerability has been resolved:
locking/ww_mutex/test: Fix potential workqueue corruption
In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be freed while they were being used.
Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely.
So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.(CVE-2023-52836)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: imsttfb: fix a resource leak in probe
I've re-written the error handling but the bug is that if init_imstt() fails we need to call iounmap(par->cmap_regs).(CVE-2023-52838)
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: wmi: Fix opening of char device
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices().
Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver.(CVE-2023-52864)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52865)
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drv_data pointer. So check if drv_data is valid before overwriting it.(CVE-2023-52871)
In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference.(CVE-2023-52875)
In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.(CVE-2023-52878)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak:
unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300
Fix this by freeing dmub_srv after destroying it.(CVE-2024-26833)
In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
Modules linked in: cryptodev(O)
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : crypto_finalize_request+0xa0/0x118
lr : crypto_finalize_request+0x104/0x118
sp : ffffffc085353ce0
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
Call trace:
crypto_finalize_request+0xa0/0x118
crypto_finalize_aead_request+0x18/0x30
zynqmp_handle_aes_req+0xcc/0x388
crypto_pump_work+0x168/0x2d8
kthread_worker_fn+0xfc/0x3a0
kthread+0x118/0x138
ret_from_fork+0x10/0x20
irq event stamp: 40
hardirqs last enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0
hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90
softirqs last enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0
softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0
---[ end trace 0000000000000000 ]---(CVE-2024-26877)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device.
The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback.
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below:
[ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2cap_chan_timeout [ 472.075308] Call Trace: [ 472.075308] <TASK> [ 472.075308] dump_stack_lvl+0x137/0x1a0 [ 472.075308] print_report+0x101/0x250 [ 472.075308] ? __virt_addr_valid+0x77/0x160 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_report+0x139/0x170 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_check_range+0x2c3/0x2e0 [ 472.075308] mutex_lock+0x68/0xc0 [ 472.075308] l2cap_chan_timeout+0x181/0x300 [ 472.075308] process_one_work+0x5d2/0xe00 [ 472.075308] worker_thread+0xe1d/0x1660 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] kthread+0x2b7/0x350 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork+0x4d/0x80 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork_asm+0x11/0x20 [ 472.075308] </TASK> [ 472.075308] ================================================================== [ 472.094860] Disabling lock debugging due to kernel taint [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 472.096136] #PF: supervisor write access in kernel mode [ 472.096136] #PF: error_code(0x0002) - not-present page [ 472.096136] PGD 0 P4D 0 [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.096136] Workqueue: events l2cap_chan_timeout [ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0 [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88 [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246 [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865 [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78 [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000 [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00 [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000 [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0 [ 472.096136] Call Trace: [ 472.096136] <TASK> [ 472.096136] ? __die_body+0x8d/0xe0 [ 472.096136] ? page_fault_oops+0x6b8/0x9a0 [ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0 [ 472.096136] ? do_user_addr_fault+0x1027/0x1340 [ 472.096136] ? _printk+0x7a/0xa0 [ 472.096136] ? mutex_lock+0x68/0xc0 [ 472.096136] ? add_taint+0x42/0xd0 [ 472.096136] ? exc_page_fault+0x6a/0x1b0 [ 472.096136] ? asm_exc_page_fault+0x26/0x30 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] ? mutex_lock+0x88/0xc0 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] l2cap_chan_timeo ---truncated---(CVE-2024-27399)
In the Linux kernel, the following vulnerability has been resolved:
firewire: nosy: ensure user_length is taken into account when fetching packet contents
Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)
In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^
Use the correct type instead here.(CVE-2024-27413)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: confirm multicast packets before passing them up the stack
conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges.
Example: macvlan0 | br0 / \ ethX ethY
ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table.
- skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry
- skb is broad/mcast packet. bridge now passes clones out on each bridge interface.
- skb gets passed up the stack.
-
In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices.
The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.
The Macvlan broadcast worker and normal confirm path will race.
This race will not happen if step 2 already confirmed a clone. In that case later steps perform skb_clone() with skb->_nfct already confirmed (in hash table). This works fine.
But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting.
Pablo points out that nf_conntrack_bridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again.
This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook.
Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry.
The downside is that this disables NAT and conntrack helpers.
Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example:
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings.
Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.(CVE-2024-27415)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change.(CVE-2024-35789)
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
usb: udc: remove warning when queue disabled ep
It is possible trigger below warning message from mass storage function,
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c
Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable.
As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)
In the Linux kernel, the following vulnerability has been resolved:
vt: fix unicode buffer corruption when deleting characters
This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.(CVE-2024-35823)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
subflow_finish_connect() uses four fields (backup, join_id, thmac, none) that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set in mptcp_parse_option()(CVE-2024-35840)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the 'vregion->lock' mutex.
[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30
Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30(CVE-2024-35855)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
<--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h>
int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map;
ring_fd = io_uring_setup(1, &p);
if (ring_fd < 0) {
perror("io_uring_setup");
return 1;
}
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
/* Map the submission queue ring MAP_PRIVATE */
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
ring_fd, IORING_OFF_SQ_RING);
if (map == MAP_FAILED) {
perror("mmap");
return 1;
}
/* We have at least one page. Let's COW it. */
*map = 0;
pause();
return 0;
} <--- C reproducer --->
On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncated---(CVE-2024-35877)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject new basechain after table flag update
When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new).
The following configuration allows for an inconsistent state:
add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; }
which triggers the following warning when trying to unregister chain w which is already unregistered.
[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260 [...] [ 127.322519] Call Trace: [ 127.322521] <TASK> [ 127.322524] ? __warn+0x9f/0x1a0 [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322537] ? report_bug+0x1b1/0x1e0 [ 127.322545] ? handle_bug+0x3c/0x70 [ 127.322552] ? exc_invalid_op+0x17/0x40 [ 127.322556] ? asm_exc_invalid_op+0x1a/0x20 [ 127.322563] ? kasan_save_free_info+0x3b/0x60 [ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables] [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables] [ 127.322717] nf_tables_commit+0x2571/0x2620 nf_tables
In the Linux kernel, the following vulnerability has been resolved:
selinux: avoid dereference of garbage after mount failure
In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer.
While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)
In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)
In the Linux kernel, the following vulnerability has been resolved:
dma-direct: Leak pages on dma_set_decrypted() failure
On TDX it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.
DMA could free decrypted/shared pages if dma_set_decrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them.(CVE-2024-35939)
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev->mode_config.mutex
The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.(CVE-2024-35950)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
Create subvolume, create snapshot and delete subvolume all use btrfs_subvolume_reserve_metadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via start_transaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction.
However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling record_root_in_trans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. Ultimately, this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount for the leaked reservation.
The fix is to ensure that every qgroup PREALLOC reservation observes the following properties:
- any failure before record_root_in_trans is called successfully results in freeing the PREALLOC reservation.
- after record_root_in_trans, we convert to PERTRANS, and now the transaction owns freeing the reservation.
This patch enforces those properties on the three operations. Without it, generic/269 with squotas enabled at mkfs time would fail in ~5-10 runs on my system. With this patch, it ran successfully 1000 times in a row.(CVE-2024-35956)
In the Linux kernel, the following vulnerability has been resolved:
net: ena: Fix incorrect descriptor free behavior
ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions
The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue.
This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.(CVE-2024-35958)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL.
This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].
This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.(CVE-2024-35960)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one.(CVE-2024-35978)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops:
BUG: unable to handle page fault for address: 000000000002a2b8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1470e1067 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
RIP: 0010:mutex_lock+0x2e/0x50
...
Call Trace:
<TASK>
__die+0x24/0x70
page_fault_oops+0x82/0x160
do_user_addr_fault+0x65/0x6b0
__pfx___rdmsr_safe_on_cpu+0x10/0x10
exc_page_fault+0x7d/0x170
asm_exc_page_fault+0x26/0x30
mutex_lock+0x2e/0x50
mutex_lock+0x1e/0x50
perf_pmu_migrate_context+0x87/0x1f0
perf_event_cpu_offline+0x76/0x90 [idxd]
cpuhp_invoke_callback+0xa2/0x4f0
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
cpuhp_thread_fun+0x98/0x150
smpboot_thread_fn+0x27/0x260
smpboot_thread_fn+0x1af/0x260
__pfx_smpboot_thread_fn+0x10/0x10
kthread+0x103/0x140
__pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
__pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
<TASK>
Fix the issue by preventing the migration of the perf context to an invalid target.(CVE-2024-35989)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix missing hugetlb_lock for resv uncharge
There is a recent report on UFFDIO_COPY over hugetlb:
https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
350: lockdep_assert_held(&hugetlb_lock);
Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held.(CVE-2024-36000)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not.
Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.
[Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40e_service_task [i40e] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? __warn+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? report_bug+0x195/0x1a0 [ +0.000005] ? handle_bug+0x3c/0x70 [ +0.000003] ? exc_invalid_op+0x14/0x70 [ +0.000002] ? asm_exc_invalid_op+0x16/0x20 [ +0.000006] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000024] process_one_work+0x174/0x340 [ +0.000003] worker_th ---truncated---(CVE-2024-36004)
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix warning during rehash
As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled.
Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1].
Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases.
[1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_afk_encode+0x242/0x2f0 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 </TASK>(CVE-2024-36007)
In the Linux kernel, the following vulnerability has been resolved:
ppdev: Add an error check in register_device
In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value.
To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.(CVE-2024-36015)
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well.(CVE-2024-36940)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"perf-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-202.0.0.115.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-headers-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"perf-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-202.0.0.115.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-202.0.0.115.oe2203sp3"
}
],
"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:\r\n\r\nRDMA: Verify port when creating flow rule\r\n\r\nValidate port value provided by the user and with that remove no longer\nneeded validation by the driver. The missing check in the mlx5_ib driver\ncould cause to the below oops.\r\n\r\nCall trace:\n _create_flow_rule+0x2d4/0xf28 [mlx5_ib]\n mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]\n ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]\n ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]\n ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]\n ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]\n do_vfs_ioctl+0xd0/0xaf0\n ksys_ioctl+0x84/0xb4\n __arm64_sys_ioctl+0x28/0xc4\n el0_svc_common.constprop.3+0xa4/0x254\n el0_svc_handler+0x84/0xa0\n el0_svc+0x10/0x26c\n Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: fix possible use-after-free in HFC_cleanup()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47356)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure tx skbs always have the MPTCP ext\r\n\r\nDue to signed/unsigned comparison, the expression:\r\n\r\n\tinfo-\u0026gt;size_goal - skb-\u0026gt;len \u0026gt; 0\r\n\r\nevaluates to true when the size goal is smaller than the\nskb size. That results in lack of tx cache refill, so that\nthe skb allocated by the core TCP code lacks the required\nMPTCP skb extensions.\r\n\r\nDue to the above, syzbot is able to trigger the following WARN_ON():\r\n\r\nWARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nModules linked in:\nCPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nCode: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 \u0026lt;0f\u0026gt; 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9\nRSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216\nRAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000\nRDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003\nRBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280\nR13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0\nFS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547\n mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003\n release_sock+0xb4/0x1b0 net/core/sock.c:3206\n sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145\n mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749\n inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n sock_write_iter+0x2a0/0x3e0 net/socket.c:1057\n call_write_iter include/linux/fs.h:2163 [inline]\n new_sync_write+0x40b/0x640 fs/read_write.c:507\n vfs_write+0x7cf/0xae0 fs/read_write.c:594\n ksys_write+0x1ee/0x250 fs/read_write.c:647\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9\nRDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003\nRBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038\nR13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000\r\n\r\nFix the issue rewriting the relevant expression to avoid\nsign-related problems - note: size_goal is always \u0026gt;= 0.\r\n\r\nAdditionally, ensure that the skb in the tx cache always carries\nthe relevant extension.(CVE-2021-47370)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: iscsi: Fix iscsi_task use after free\r\n\r\nCommit d39df158518c (\u0026quot;scsi: iscsi: Have abort handler get ref to conn\u0026quot;)\nadded iscsi_get_conn()/iscsi_put_conn() calls during abort handling but\nthen also changed the handling of the case where we detect an already\ncompleted task where we now end up doing a goto to the common put/cleanup\ncode. This results in a iscsi_task use after free, because the common\ncleanup code will do a put on the iscsi_task.\r\n\r\nThis reverts the goto and moves the iscsi_get_conn() to after we\u0026apos;ve checked\nif the iscsi_task is valid.(CVE-2021-47427)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix even more out of bound writes from debugfs\r\n\r\nCVE-2021-42327 was fixed by:\r\n\r\ncommit f23750b5b3d98653b31d4469592935ef6364ad67\nAuthor: Thelford Williams \u0026lt;tdwilliamsiv@gmail.com\u0026gt;\nDate: Wed Oct 13 16:04:13 2021 -0400\r\n\r\n drm/amdgpu: fix out of bounds write\r\n\r\nbut amdgpu_dm_debugfs.c contains more of the same issue so fix the\nremaining ones.\r\n\r\nv2:\n\t* Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: TX zerocopy should not sense pfmemalloc status\r\n\r\nWe got a recent syzbot report [1] showing a possible misuse\nof pfmemalloc page status in TCP zerocopy paths.\r\n\r\nIndeed, for pages coming from user space or other layers,\nusing page_is_pfmemalloc() is moot, and possibly could give\nfalse positives.\r\n\r\nThere has been attempts to make page_is_pfmemalloc() more robust,\nbut not using it in the first place in this context is probably better,\nremoving cpu cycles.\r\n\r\nNote to stable teams :\r\n\r\nYou need to backport 84ce071e38a6 (\u0026quot;net: introduce\n__skb_fill_page_desc_noacc\u0026quot;) as a prereq.\r\n\r\nRace is more probable after commit c07aea3ef4d4\n(\u0026quot;mm: add a signature in struct page\u0026quot;) because page_is_pfmemalloc()\nis now using low order bit from page-\u0026gt;lru.next, which can change\nmore often than page-\u0026gt;index.\r\n\r\nLow order bit should never be set for lru.next (when used as an anchor\nin LRU list), so KCSAN report is mostly a false positive.\r\n\r\nBackporting to older kernel versions seems not necessary.\r\n\r\n[1]\nBUG: KCSAN: data-race in lru_add_fn / tcp_build_frag\r\n\r\nwrite to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:105 [inline]\nlru_add_fn+0x440/0x520 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nfolio_batch_add_and_move mm/swap.c:263 [inline]\nfolio_add_lru+0xf1/0x140 mm/swap.c:490\nfilemap_add_folio+0xf8/0x150 mm/filemap.c:948\n__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981\npagecache_get_page+0x26/0x190 mm/folio-compat.c:104\ngrab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116\next4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988\ngeneric_perform_write+0x1d4/0x3f0 mm/filemap.c:3738\next4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270\next4_file_write_iter+0x2e3/0x1210\ncall_write_iter include/linux/fs.h:2187 [inline]\nnew_sync_write fs/read_write.c:491 [inline]\nvfs_write+0x468/0x760 fs/read_write.c:578\nksys_write+0xe8/0x1a0 fs/read_write.c:631\n__do_sys_write fs/read_write.c:643 [inline]\n__se_sys_write fs/read_write.c:640 [inline]\n__x64_sys_write+0x3e/0x50 fs/read_write.c:640\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nread to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1740 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2443 [inline]\ntcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018\ndo_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075\ntcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]\ntcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150\ninet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1249\n__do_sys_sendfile64 fs/read_write.c:1317 [inline]\n__se_sys_sendfile64 fs/read_write.c:1303 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\r\n\r\nvalue changed: 0x0000000000000000 -\u0026gt; 0xffffea0004a1d288\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring/af_unix: disable sending io_uring over sockets\r\n\r\nFile reference cycles have caused lots of problems for io_uring\nin the past, and it still doesn\u0026apos;t work exactly right and races with\nunix_stream_read_generic(). The safest fix would be to completely\ndisallow sending io_uring files via sockets via SCM_RIGHT, so there\nare no possible cycles invloving registered files and thus rendering\nSCM accounting on the io_uring side unnecessary.(CVE-2023-52654)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: s390/aes - Fix buffer overread in CTR mode\r\n\r\nWhen processing the last block, the s390 ctr code will always read\na whole block, even if there isn\u0026apos;t a whole block of data left. Fix\nthis by using the actual length left and copy it into a buffer first\nfor processing.(CVE-2023-52669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: Check if the code to patch lies in the exit section\r\n\r\nOtherwise we fall through to vmalloc_to_page() which panics since the\naddress does not lie in the vmalloc region.(CVE-2023-52677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_powercap_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysv: don\u0026apos;t call sb_bread() with pointers_lock held\r\n\r\nsyzbot is reporting sleep in atomic context in SysV filesystem [1], for\nsb_bread() is called with rw_spinlock held.\r\n\r\nA \u0026quot;write_lock(\u0026amp;pointers_lock) =\u0026gt; read_lock(\u0026amp;pointers_lock) deadlock\u0026quot; bug\nand a \u0026quot;sb_bread() with write_lock(\u0026amp;pointers_lock)\u0026quot; bug were introduced by\n\u0026quot;Replace BKL for chain locking with sysvfs-private rwlock\u0026quot; in Linux 2.5.12.\r\n\r\nThen, \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; in Linux 2.6.8 fixed the\nformer bug by moving pointers_lock lock to the callers, but instead\nintroduced a \u0026quot;sb_bread() with read_lock(\u0026amp;pointers_lock)\u0026quot; bug (which made\nthis problem easier to hit).\r\n\r\nAl Viro suggested that why not to do like get_branch()/get_block()/\nfind_shared() in Minix filesystem does. And doing like that is almost a\nrevert of \u0026quot;[PATCH] err1-40: sysvfs locking fix\u0026quot; except that get_branch()\n from with find_shared() is called without write_lock(\u0026amp;pointers_lock).(CVE-2023-52699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer\r\n\r\nPrior to LLVM 15.0.0, LLVM\u0026apos;s integrated assembler would incorrectly\nbyte-swap NOP when compiling for big-endian, and the resulting series of\nbytes happened to match the encoding of FNMADD S21, S30, S0, S0.\r\n\r\nThis went unnoticed until commit:\r\n\r\n 34f66c4c4d5518c1 (\u0026quot;arm64: Use a positive cpucap for FP/SIMD\u0026quot;)\r\n\r\nPrior to that commit, the kernel would always enable the use of FPSIMD\nearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage of\nFNMADD within the kernel was not detected, but could result in the\ncorruption of user or kernel FPSIMD state.\r\n\r\nAfter that commit, the instructions happen to trap during boot prior to\nFPSIMD being detected and enabled, e.g.\r\n\r\n| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : __pi_strcmp+0x1c/0x150\n| lr : populate_properties+0xe4/0x254\n| sp : ffffd014173d3ad0\n| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000\n| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008\n| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044\n| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005\n| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000\n| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000\n| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000\n| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000\n| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a\n| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8\n| Kernel panic - not syncing: Unhandled exception\n| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1\n| Hardware name: linux,dummy-virt (DT)\n| Call trace:\n| dump_backtrace+0xec/0x108\n| show_stack+0x18/0x2c\n| dump_stack_lvl+0x50/0x68\n| dump_stack+0x18/0x24\n| panic+0x13c/0x340\n| el1t_64_irq_handler+0x0/0x1c\n| el1_abort+0x0/0x5c\n| el1h_64_sync+0x64/0x68\n| __pi_strcmp+0x1c/0x150\n| unflatten_dt_nodes+0x1e8/0x2d8\n| __unflatten_device_tree+0x5c/0x15c\n| unflatten_device_tree+0x38/0x50\n| setup_arch+0x164/0x1e0\n| start_kernel+0x64/0x38c\n| __primary_switched+0xbc/0xc4\r\n\r\nRestrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is\neither GNU as or LLVM\u0026apos;s IAS 15.0.0 and newer, which contains the linked\ncommit.(CVE-2023-52750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb: client: fix use-after-free bug in cifs_debug_data_proc_show()\r\n\r\nSkip SMB sessions that are being teared down\n(e.g. @ses-\u0026gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()\nto avoid use-after-free in @ses.\r\n\r\nThis fixes the following GPF when reading from /proc/fs/cifs/DebugData\nwhile mounting and umounting\r\n\r\n [ 816.251274] general protection fault, probably for non-canonical\n address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI\n ...\n [ 816.260138] Call Trace:\n [ 816.260329] \u0026lt;TASK\u0026gt;\n [ 816.260499] ? die_addr+0x36/0x90\n [ 816.260762] ? exc_general_protection+0x1b3/0x410\n [ 816.261126] ? asm_exc_general_protection+0x26/0x30\n [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]\n [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]\n [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]\n [ 816.262689] ? seq_read_iter+0x379/0x470\n [ 816.262995] seq_read_iter+0x118/0x470\n [ 816.263291] proc_reg_read_iter+0x53/0x90\n [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f\n [ 816.263945] vfs_read+0x201/0x350\n [ 816.264211] ksys_read+0x75/0x100\n [ 816.264472] do_syscall_64+0x3f/0x90\n [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Avoid NULL dereference of timing generator\r\n\r\n[Why \u0026amp; How]\nCheck whether assigned timing generator is NULL or not before\naccessing its funcs to prevent NULL dereference.(CVE-2023-52753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npwm: Fix double shift bug\r\n\r\nThese enums are passed to set/test_bit(). The set/test_bit() functions\ntake a bit number instead of a shifted value. Passing a shifted value\nis a double shift bug like doing BIT(BIT(1)). The double shift bug\ndoesn\u0026apos;t cause a problem here because we are only checking 0 and 1 but\nif the value was 5 or above then it can lead to a buffer overflow.(CVE-2023-52756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: ignore negated quota changes\r\n\r\nWhen lots of quota changes are made, there may be cases in which an\ninode\u0026apos;s quota information is increased and then decreased, such as when\nblocks are added to a file, then deleted from it. If the timing is\nright, function do_qc can add pending quota changes to a transaction,\nthen later, another call to do_qc can negate those changes, resulting\nin a net gain of 0. The quota_change information is recorded in the qc\nbuffer (and qd element of the inode as well). The buffer is added to the\ntransaction by the first call to do_qc, but a subsequent call changes\nthe value from non-zero back to zero. At that point it\u0026apos;s too late to\nremove the buffer_head from the transaction. Later, when the quota sync\ncode is called, the zero-change qd element is discovered and flagged as\nan assert warning. If the fs is mounted with errors=panic, the kernel\nwill panic.\r\n\r\nThis is usually seen when files are truncated and the quota changes are\nnegated by punch_hole/truncate which uses gfs2_quota_hold and\ngfs2_quota_unhold rather than block allocations that use gfs2_quota_lock\nand gfs2_quota_unlock which automatically do quota sync.\r\n\r\nThis patch solves the problem by adding a check to qd_check_sync such\nthat net-zero quota changes already added to the transaction are no\nlonger deemed necessary to be synced, and skipped.\r\n\r\nIn this case references are taken for the qd and the slot from do_qc\nso those need to be put. The normal sequence of events for a normal\nnon-zero quota change is as follows:\r\n\r\ngfs2_quota_change\n do_qc\n qd_hold\n slot_hold\r\n\r\nLater, when the changes are to be synced:\r\n\r\ngfs2_quota_sync\n qd_fish\n qd_check_sync\n gets qd ref via lockref_get_not_dead\n do_sync\n do_qc(QC_SYNC)\n qd_put\n\t lockref_put_or_lock\n qd_unlock\n qd_put\n lockref_put_or_lock\r\n\r\nIn the net-zero change case, we add a check to qd_check_sync so it puts\nthe qd and slot references acquired in gfs2_quota_change and skip the\nunneeded sync.(CVE-2023-52759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: protect device queue against concurrent access\r\n\r\nIn dasd_profile_start() the amount of requests on the device queue are\ncounted. The access to the device queue is unprotected against\nconcurrent access. With a lot of parallel I/O, especially with alias\ndevices enabled, the device queue can change while dasd_profile_start()\nis accessing the queue. In the worst case this leads to a kernel panic\ndue to incorrect pointer accesses.\r\n\r\nFix this by taking the device lock before accessing the queue and\ncounting the requests. Additionally the check for a valid profile data\npointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntty: vcc: Add check for kstrdup() in vcc_probe()\r\n\r\nAdd check for the return value of kstrdup() and return the error, if it\nfails in order to avoid NULL pointer dereference.(CVE-2023-52789)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvhost-vdpa: fix use after free in vhost_vdpa_probe()\r\n\r\nThe put_device() calls vhost_vdpa_release_dev() which calls\nida_simple_remove() and frees \u0026quot;v\u0026quot;. So this call to\nida_simple_remove() is a use after free and a double free.(CVE-2023-52795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvlan: add ipvlan_route_v6_outbound() helper\r\n\r\nInspired by syzbot reports using a stack of multiple ipvlan devices.\r\n\r\nReduce stack size needed in ipvlan_process_v6_outbound() by moving\nthe flowi6 struct used for the route lookup in an non inlined\nhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,\nimmediately reclaimed.\r\n\r\nAlso make sure ipvlan_process_v4_outbound() is not inlined.\r\n\r\nWe might also have to lower MAX_NEST_DEV, because only syzbot uses\nsetups with more than four stacked devices.\r\n\r\nBUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)\nstack guard page: 0000 [#1] SMP KASAN\nCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023\nRIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188\nCode: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 \u0026lt;41\u0026gt; 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89\nRSP: 0018:ffffc9000e804000 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2\nRDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568\nRBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c\nR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000\nFS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;#DF\u0026gt;\n\u0026lt;/#DF\u0026gt;\n\u0026lt;TASK\u0026gt;\n[\u0026lt;ffffffff81f281d1\u0026gt;] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31\n[\u0026lt;ffffffff817e5bf2\u0026gt;] instrument_atomic_read include/linux/instrumented.h:72 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpumask_test_cpu include/linux/cpumask.h:506 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] cpu_online include/linux/cpumask.h:1092 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] trace_lock_acquire include/trace/events/lock.h:24 [inline]\n[\u0026lt;ffffffff817e5bf2\u0026gt;] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632\n[\u0026lt;ffffffff8563221e\u0026gt;] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306\n[\u0026lt;ffffffff8561464d\u0026gt;] rcu_read_lock include/linux/rcupdate.h:747 [inline]\n[\u0026lt;ffffffff8561464d\u0026gt;] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221\n[\u0026lt;ffffffff85618120\u0026gt;] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606\n[\u0026lt;ffffffff856f65b5\u0026gt;] pol_lookup_func include/net/ip6_fib.h:584 [inline]\n[\u0026lt;ffffffff856f65b5\u0026gt;] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116\n[\u0026lt;ffffffff85618009\u0026gt;] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638\n[\u0026lt;ffffffff8561821a\u0026gt;] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ip6_route_output include/net/ip6_route.h:100 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n[\u0026lt;ffffffff838bd5a3\u0026gt;] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677\n[\u0026lt;ffffffff838c2909\u0026gt;] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229\n[\u0026lt;ffffffff84d03900\u0026gt;] netdev_start_xmit include/linux/netdevice.h:4966 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] xmit_one net/core/dev.c:3644 [inline]\n[\u0026lt;ffffffff84d03900\u0026gt;] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660\n[\u0026lt;ffffffff84d080e2\u0026gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324\n[\u0026lt;ffffffff855ce4cd\u0026gt;] dev_queue_xmit include/linux/netdevice.h:3067 [inline]\n[\u0026lt;ffffffff855ce4cd\u0026gt;] neigh_hh_output include/net/neighbour.h:529 [inline]\n[\u0026lt;f\n---truncated---(CVE-2023-52796)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath11k: fix dfs radar event locking\r\n\r\nThe ath11k active pdevs are protected by RCU but the DFS radar event\nhandling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a\nread-side critical section.\r\n\r\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\r\n\r\nCompile tested only.(CVE-2023-52798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in dbFindLeaf\r\n\r\nCurrently while searching for dmtree_t for sufficient free blocks there\nis an array out of bounds while getting element in tp-\u0026gt;dm_stree. To add\nthe required check for out of bound we first need to determine the type\nof dmtree. Thus added an extra parameter to dbFindLeaf so that the type\nof tree can be determined and the required check can be applied.(CVE-2023-52799)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath11k: fix htt pktlog locking\r\n\r\nThe ath11k active pdevs are protected by RCU but the htt pktlog handling\ncode calling ath11k_mac_get_ar_by_pdev_id() was not marked as a\nread-side critical section.\r\n\r\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\r\n\r\nCompile tested only.(CVE-2023-52800)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()\r\n\r\nof_match_device() may fail and returns a NULL pointer.\r\n\r\nIn practice there is no known reasonable way to trigger this, but\nin case one is added in future, harden the code by adding the check(CVE-2023-52802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix potential null pointer derefernce\r\n\r\nThe amdgpu_ras_get_context may return NULL if device\nnot support ras feature, so add check before using.(CVE-2023-52814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/panel/panel-tpo-tpg110: fix a possible null pointer dereference\r\n\r\nIn tpg110_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpu/hotplug: Don\u0026apos;t offline the last non-isolated CPU\r\n\r\nIf a system has isolated CPUs via the \u0026quot;isolcpus=\u0026quot; command line parameter,\nthen an attempt to offline the last housekeeping CPU will result in a\nWARN_ON() when rebuilding the scheduler domains and a subsequent panic due\nto and unhandled empty CPU mas in partition_sched_domains_locked().\r\n\r\ncpuset_hotplug_workfn()\n rebuild_sched_domains_locked()\n ndoms = generate_sched_domains(\u0026amp;doms, \u0026amp;attr);\n cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));\r\n\r\nThus results in an empty CPU mask which triggers the warning and then the\nsubsequent crash:\r\n\r\nWARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408\nCall trace:\n build_sched_domains+0x120c/0x1408\n partition_sched_domains_locked+0x234/0x880\n rebuild_sched_domains_locked+0x37c/0x798\n rebuild_sched_domains+0x30/0x58\n cpuset_hotplug_workfn+0x2a8/0x930\r\n\r\nUnable to handle kernel paging request at virtual address fffe80027ab37080\n partition_sched_domains_locked+0x318/0x880\n rebuild_sched_domains_locked+0x37c/0x798\r\n\r\nAside of the resulting crash, it does not make any sense to offline the last\nlast housekeeping CPU.\r\n\r\nPrevent this by masking out the non-housekeeping CPUs when selecting a\ntarget CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: don\u0026apos;t return unset power in ieee80211_get_tx_power()\r\n\r\nWe can get a UBSAN warning if ieee80211_get_tx_power() returns the\nINT_MIN value mac80211 internally uses for \u0026quot;unset power level\u0026quot;.\r\n\r\n UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5\n -2147483648 * 100 cannot be represented in type \u0026apos;int\u0026apos;\n CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE\n Call Trace:\n dump_stack+0x74/0x92\n ubsan_epilogue+0x9/0x50\n handle_overflow+0x8d/0xd0\n __ubsan_handle_mul_overflow+0xe/0x10\n nl80211_send_iface+0x688/0x6b0 [cfg80211]\n [...]\n cfg80211_register_wdev+0x78/0xb0 [cfg80211]\n cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]\n [...]\n ieee80211_if_add+0x60e/0x8f0 [mac80211]\n ieee80211_register_hw+0xda5/0x1170 [mac80211]\r\n\r\nIn this case, simply return an error instead, to indicate\nthat no data is available.(CVE-2023-52832)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlocking/ww_mutex/test: Fix potential workqueue corruption\r\n\r\nIn some cases running with the test-ww_mutex code, I was seeing\nodd behavior where sometimes it seemed flush_workqueue was\nreturning before all the work threads were finished.\r\n\r\nOften this would cause strange crashes as the mutexes would be\nfreed while they were being used.\r\n\r\nLooking at the code, there is a lifetime problem as the\ncontrolling thread that spawns the work allocates the\n\u0026quot;struct stress\u0026quot; structures that are passed to the workqueue\nthreads. Then when the workqueue threads are finished,\nthey free the stress struct that was passed to them.\r\n\r\nUnfortunately the workqueue work_struct node is in the stress\nstruct. Which means the work_struct is freed before the work\nthread returns and while flush_workqueue is waiting.\r\n\r\nIt seems like a better idea to have the controlling thread\nboth allocate and free the stress structures, so that we can\nbe sure we don\u0026apos;t corrupt the workqueue by freeing the structure\nprematurely.\r\n\r\nSo this patch reworks the test to do so, and with this change\nI no longer see the early flush_workqueue returns.(CVE-2023-52836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: imsttfb: fix a resource leak in probe\r\n\r\nI\u0026apos;ve re-written the error handling but the bug is that if init_imstt()\nfails we need to call iounmap(par-\u0026gt;cmap_regs).(CVE-2023-52838)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nplatform/x86: wmi: Fix opening of char device\r\n\r\nSince commit fa1f68db6ca7 (\u0026quot;drivers: misc: pass miscdevice pointer via\nfile private data\u0026quot;), the miscdevice stores a pointer to itself inside\nfilp-\u0026gt;private_data, which means that private_data will not be NULL when\nwmi_char_open() is called. This might cause memory corruption should\nwmi_char_open() be unable to find its driver, something which can\nhappen when the associated WMI device is deleted in wmi_free_devices().\r\n\r\nFix the problem by using the miscdevice pointer to retrieve the WMI\ndevice data associated with a char device using container_of(). This\nalso avoids wmi_char_open() picking a wrong WMI device bound to a\ndriver with the same name as the original driver.(CVE-2023-52864)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: llcc: Handle a second device without data corruption\r\n\r\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it.(CVE-2023-52871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: dev: can_put_echo_skb(): don\u0026apos;t crash kernel if can_priv::echo_skb is accessed out of bounds\r\n\r\nIf the \u0026quot;struct can_priv::echoo_skb\u0026quot; is accessed out of bounds, this\nwould cause a kernel crash. Instead, issue a meaningful warning\nmessage and return with an error.(CVE-2023-52878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix memory leak in dm_sw_fini()\r\n\r\nAfter destroying dmub_srv, the memory associated with it is\nnot freed, causing a memory leak:\r\n\r\nunreferenced object 0xffff896302b45800 (size 1024):\n comm \u0026quot;(udev-worker)\u0026quot;, pid 222, jiffies 4294894636\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 6265fd77):\n [\u0026lt;ffffffff993495ed\u0026gt;] kmalloc_trace+0x29d/0x340\n [\u0026lt;ffffffffc0ea4a94\u0026gt;] dm_dmub_sw_init+0xb4/0x450 [amdgpu]\n [\u0026lt;ffffffffc0ea4e55\u0026gt;] dm_sw_init+0x15/0x2b0 [amdgpu]\n [\u0026lt;ffffffffc0ba8557\u0026gt;] amdgpu_device_init+0x1417/0x24e0 [amdgpu]\n [\u0026lt;ffffffffc0bab285\u0026gt;] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]\n [\u0026lt;ffffffffc0ba09c7\u0026gt;] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]\n [\u0026lt;ffffffff9968fd1e\u0026gt;] local_pci_probe+0x3e/0x90\n [\u0026lt;ffffffff996918a3\u0026gt;] pci_device_probe+0xc3/0x230\n [\u0026lt;ffffffff99805872\u0026gt;] really_probe+0xe2/0x480\n [\u0026lt;ffffffff99805c98\u0026gt;] __driver_probe_device+0x78/0x160\n [\u0026lt;ffffffff99805daf\u0026gt;] driver_probe_device+0x1f/0x90\n [\u0026lt;ffffffff9980601e\u0026gt;] __driver_attach+0xce/0x1c0\n [\u0026lt;ffffffff99803170\u0026gt;] bus_for_each_dev+0x70/0xc0\n [\u0026lt;ffffffff99804822\u0026gt;] bus_add_driver+0x112/0x210\n [\u0026lt;ffffffff99807245\u0026gt;] driver_register+0x55/0x100\n [\u0026lt;ffffffff990012d1\u0026gt;] do_one_initcall+0x41/0x300\r\n\r\nFix this by freeing dmub_srv after destroying it.(CVE-2024-26833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: xilinx - call finalize with bh disabled\r\n\r\nWhen calling crypto_finalize_request, BH should be disabled to avoid\ntriggering the following calltrace:\r\n\r\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118\n Modules linked in: cryptodev(O)\n CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323\n Hardware name: ZynqMP ZCU102 Rev1.0 (DT)\n pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : crypto_finalize_request+0xa0/0x118\n lr : crypto_finalize_request+0x104/0x118\n sp : ffffffc085353ce0\n x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688\n x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00\n x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000\n x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0\n x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8\n x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001\n x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000\n x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000\n Call trace:\n crypto_finalize_request+0xa0/0x118\n crypto_finalize_aead_request+0x18/0x30\n zynqmp_handle_aes_req+0xcc/0x388\n crypto_pump_work+0x168/0x2d8\n kthread_worker_fn+0xfc/0x3a0\n kthread+0x118/0x138\n ret_from_fork+0x10/0x20\n irq event stamp: 40\n hardirqs last enabled at (39): [\u0026lt;ffffffc0812416f8\u0026gt;] _raw_spin_unlock_irqrestore+0x70/0xb0\n hardirqs last disabled at (40): [\u0026lt;ffffffc08122d208\u0026gt;] el1_dbg+0x28/0x90\n softirqs last enabled at (36): [\u0026lt;ffffffc080017dec\u0026gt;] kernel_neon_begin+0x8c/0xf0\n softirqs last disabled at (34): [\u0026lt;ffffffc080017dc0\u0026gt;] kernel_neon_begin+0x60/0xf0\n ---[ end trace 0000000000000000 ]---(CVE-2024-26877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: core: Fix deadlock in usb_deauthorize_interface()\r\n\r\nAmong the attribute file callback routines in\ndrivers/usb/core/sysfs.c, the interface_authorized_store() function is\nthe only one which acquires a device lock on an ancestor device: It\ncalls usb_deauthorize_interface(), which locks the interface\u0026apos;s parent\nUSB device.\r\n\r\nThe will lead to deadlock if another process already owns that lock\nand tries to remove the interface, whether through a configuration\nchange or because the device has been disconnected. As part of the\nremoval procedure, device_del() waits for all ongoing sysfs attribute\ncallbacks to complete. But usb_deauthorize_interface() can\u0026apos;t complete\nuntil the device lock has been released, and the lock won\u0026apos;t be\nreleased until the removal has finished.\r\n\r\nThe mechanism provided by sysfs to prevent this kind of deadlock is\nto use the sysfs_break_active_protection() function, which tells sysfs\nnot to wait for the attribute callback.\r\n\r\nReported-and-tested by: Yue Sun \u0026lt;samsun1006219@gmail.com\u0026gt;\nReported by: xingwei lee \u0026lt;xrivendell7@gmail.com\u0026gt;(CVE-2024-26934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()\r\n\r\nnft_unregister_expr() can concurrent with __nft_expr_type_get(),\nand there is not any protection when iterate over nf_tables_expressions\nlist in __nft_expr_type_get(). Therefore, there is potential data-race\nof nf_tables_expressions list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_expressions\nlist in __nft_expr_type_get(), and use rcu_read_lock() in the caller\nnft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout\r\n\r\nThere is a race condition between l2cap_chan_timeout() and\nl2cap_chan_del(). When we use l2cap_chan_del() to delete the\nchannel, the chan-\u0026gt;conn will be set to null. But the conn could\nbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().\nAs a result the null pointer dereference bug will happen. The\nKASAN report triggered by POC is shown below:\r\n\r\n[ 472.074580] ==================================================================\n[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0\n[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7\n[ 472.075308]\n[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.075308] Workqueue: events l2cap_chan_timeout\n[ 472.075308] Call Trace:\n[ 472.075308] \u0026lt;TASK\u0026gt;\n[ 472.075308] dump_stack_lvl+0x137/0x1a0\n[ 472.075308] print_report+0x101/0x250\n[ 472.075308] ? __virt_addr_valid+0x77/0x160\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_report+0x139/0x170\n[ 472.075308] ? mutex_lock+0x68/0xc0\n[ 472.075308] kasan_check_range+0x2c3/0x2e0\n[ 472.075308] mutex_lock+0x68/0xc0\n[ 472.075308] l2cap_chan_timeout+0x181/0x300\n[ 472.075308] process_one_work+0x5d2/0xe00\n[ 472.075308] worker_thread+0xe1d/0x1660\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] kthread+0x2b7/0x350\n[ 472.075308] ? pr_cont_work+0x5e0/0x5e0\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork+0x4d/0x80\n[ 472.075308] ? kthread_blkcg+0xd0/0xd0\n[ 472.075308] ret_from_fork_asm+0x11/0x20\n[ 472.075308] \u0026lt;/TASK\u0026gt;\n[ 472.075308] ==================================================================\n[ 472.094860] Disabling lock debugging due to kernel taint\n[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158\n[ 472.096136] #PF: supervisor write access in kernel mode\n[ 472.096136] #PF: error_code(0x0002) - not-present page\n[ 472.096136] PGD 0 P4D 0\n[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI\n[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36\n[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4\n[ 472.096136] Workqueue: events l2cap_chan_timeout\n[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0\n[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88\n[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246\n[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865\n[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78\n[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f\n[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000\n[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00\n[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000\n[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0\n[ 472.096136] Call Trace:\n[ 472.096136] \u0026lt;TASK\u0026gt;\n[ 472.096136] ? __die_body+0x8d/0xe0\n[ 472.096136] ? page_fault_oops+0x6b8/0x9a0\n[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0\n[ 472.096136] ? do_user_addr_fault+0x1027/0x1340\n[ 472.096136] ? _printk+0x7a/0xa0\n[ 472.096136] ? mutex_lock+0x68/0xc0\n[ 472.096136] ? add_taint+0x42/0xd0\n[ 472.096136] ? exc_page_fault+0x6a/0x1b0\n[ 472.096136] ? asm_exc_page_fault+0x26/0x30\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] ? mutex_lock+0x88/0xc0\n[ 472.096136] ? mutex_lock+0x75/0xc0\n[ 472.096136] l2cap_chan_timeo\n---truncated---(CVE-2024-27399)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: nosy: ensure user_length is taken into account when fetching packet contents\r\n\r\nEnsure that packet_buffer_get respects the user_length provided. If\nthe length of the head packet exceeds the user_length, packet_buffer_get\nwill now return 0 to signify to the user that no data were read\nand a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi/capsule-loader: fix incorrect allocation size\r\n\r\ngcc-14 notices that the allocation with sizeof(void) on 32-bit architectures\nis not enough for a 64-bit phys_addr_t:\r\n\r\ndrivers/firmware/efi/capsule-loader.c: In function \u0026apos;efi_capsule_open\u0026apos;:\ndrivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size \u0026apos;4\u0026apos; for type \u0026apos;phys_addr_t\u0026apos; {aka \u0026apos;long long unsigned int\u0026apos;} with size \u0026apos;8\u0026apos; [-Werror=alloc-size]\n 295 | cap_info-\u0026gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);\n | ^\r\n\r\nUse the correct type instead here.(CVE-2024-27413)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: bridge: confirm multicast packets before passing them up the stack\r\n\r\nconntrack nf_confirm logic cannot handle cloned skbs referencing\nthe same nf_conn entry, which will happen for multicast (broadcast)\nframes on bridges.\r\n\r\n Example:\n macvlan0\n |\n br0\n / \\\n ethX ethY\r\n\r\n ethX (or Y) receives a L2 multicast or broadcast packet containing\n an IP packet, flow is not yet in conntrack table.\r\n\r\n 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.\n -\u0026gt; skb-\u0026gt;_nfct now references a unconfirmed entry\n 2. skb is broad/mcast packet. bridge now passes clones out on each bridge\n interface.\n 3. skb gets passed up the stack.\n 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb\n and schedules a work queue to send them out on the lower devices.\r\n\r\n The clone skb-\u0026gt;_nfct is not a copy, it is the same entry as the\n original skb. The macvlan rx handler then returns RX_HANDLER_PASS.\n 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.\r\n\r\nThe Macvlan broadcast worker and normal confirm path will race.\r\n\r\nThis race will not happen if step 2 already confirmed a clone. In that\ncase later steps perform skb_clone() with skb-\u0026gt;_nfct already confirmed (in\nhash table). This works fine.\r\n\r\nBut such confirmation won\u0026apos;t happen when eb/ip/nftables rules dropped the\npackets before they reached the nf_confirm step in postrouting.\r\n\r\nPablo points out that nf_conntrack_bridge doesn\u0026apos;t allow use of stateful\nnat, so we can safely discard the nf_conn entry and let inet call\nconntrack again.\r\n\r\nThis doesn\u0026apos;t work for bridge netfilter: skb could have a nat\ntransformation. Also bridge nf prevents re-invocation of inet prerouting\nvia \u0026apos;sabotage_in\u0026apos; hook.\r\n\r\nWork around this problem by explicit confirmation of the entry at LOCAL_IN\ntime, before upper layer has a chance to clone the unconfirmed entry.\r\n\r\nThe downside is that this disables NAT and conntrack helpers.\r\n\r\nAlternative fix would be to add locking to all code parts that deal with\nunconfirmed packets, but even if that could be done in a sane way this\nopens up other problems, for example:\r\n\r\n-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4\n-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5\r\n\r\nFor multicast case, only one of such conflicting mappings will be\ncreated, conntrack only handles 1:1 NAT mappings.\r\n\r\nUsers should set create a setup that explicitly marks such traffic\nNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass\nthem, ruleset might have accept rules for untracked traffic already,\nso user-visible behaviour would change.(CVE-2024-27415)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes\r\n\r\nWhen moving a station out of a VLAN and deleting the VLAN afterwards, the\nfast_rx entry still holds a pointer to the VLAN\u0026apos;s netdev, which can cause\nuse-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx\nafter the VLAN change.(CVE-2024-35789)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\r\n\r\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\r\n\r\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\r\n\r\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: udc: remove warning when queue disabled ep\r\n\r\nIt is possible trigger below warning message from mass storage function,\r\n\r\nWARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104\npc : usb_ep_queue+0x7c/0x104\nlr : fsg_main_thread+0x494/0x1b3c\r\n\r\nRoot cause is mass storage function try to queue request from main thread,\nbut other thread may already disable ep when function disable.\r\n\r\nAs there is no function failure in the driver, in order to avoid effort\nto fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvt: fix unicode buffer corruption when deleting characters\r\n\r\nThis is the same issue that was fixed for the VGA text buffer in commit\n39cdb68c64d8 (\u0026quot;vt: fix memory overlapping when deleting chars in the\nbuffer\u0026quot;). The cure is also the same i.e. replace memcpy() with memmove()\ndue to the overlaping buffers.(CVE-2024-35823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()\r\n\r\nsubflow_finish_connect() uses four fields (backup, join_id, thmac, none)\nthat may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set\nin mptcp_parse_option()(CVE-2024-35840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update\r\n\r\nThe rule activity update delayed work periodically traverses the list of\nconfigured rules and queries their activity from the device.\r\n\r\nAs part of this task it accesses the entry pointed by \u0026apos;ventry-\u0026gt;entry\u0026apos;,\nbut this entry can be changed concurrently by the rehash delayed work,\nleading to a use-after-free [1].\r\n\r\nFix by closing the race and perform the activity query under the\n\u0026apos;vregion-\u0026gt;lock\u0026apos; mutex.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140\nRead of size 8 at addr ffff8881054ed808 by task kworker/0:18/181\r\n\r\nCPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140\n mlxsw_sp_acl_rule_activity_update_work+0x219/0x400\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 1039:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n __kmalloc+0x19c/0x360\n mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30\r\n\r\nFreed by task 1039:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x102/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xc1/0x290\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300\n process_one_work+0x8eb/0x19b0\n worker_thread+0x6c9/0xf70\n kthread+0x2c9/0x3b0\n ret_from_fork+0x4d/0x80\n ret_from_fork_asm+0x1a/0x30(CVE-2024-35855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm/pat: fix VM_PAT handling in COW mappings\r\n\r\nPAT handling won\u0026apos;t do the right thing in COW mappings: the first PTE (or,\nin fact, all PTEs) can be replaced during write faults to point at anon\nfolios. Reliably recovering the correct PFN and cachemode using\nfollow_phys() from PTEs will not work in COW mappings.\r\n\r\nUsing follow_phys(), we might just get the address+protection of the anon\nfolio (which is very wrong), or fail on swap/nonswap entries, failing\nfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and\ntrack_pfn_copy(), not properly calling free_pfn_range().\r\n\r\nIn free_pfn_range(), we either wouldn\u0026apos;t call memtype_free() or would call\nit with the wrong range, possibly leaking memory.\r\n\r\nTo fix that, let\u0026apos;s update follow_phys() to refuse returning anon folios,\nand fallback to using the stored PFN inside vma-\u0026gt;vm_pgoff for COW mappings\nif we run into that.\r\n\r\nWe will now properly handle untrack_pfn() with COW mappings, where we\ndon\u0026apos;t need the cachemode. We\u0026apos;ll have to fail fork()-\u0026gt;track_pfn_copy() if\nthe first page was replaced by an anon folio, though: we\u0026apos;d have to store\nthe cachemode in the VMA to make this work, likely growing the VMA size.\r\n\r\nFor now, lets keep it simple and let track_pfn_copy() just fail in that\ncase: it would have failed in the past with swap/nonswap entries already,\nand it would have done the wrong thing with anon folios.\r\n\r\nSimple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():\r\n\r\n\u0026lt;--- C reproducer ---\u0026gt;\n #include \u0026lt;stdio.h\u0026gt;\n #include \u0026lt;sys/mman.h\u0026gt;\n #include \u0026lt;unistd.h\u0026gt;\n #include \u0026lt;liburing.h\u0026gt;\r\n\r\n int main(void)\n {\n struct io_uring_params p = {};\n int ring_fd;\n size_t size;\n char *map;\r\n\r\n ring_fd = io_uring_setup(1, \u0026amp;p);\n if (ring_fd \u0026lt; 0) {\n perror(\u0026quot;io_uring_setup\u0026quot;);\n return 1;\n }\n size = p.sq_off.array + p.sq_entries * sizeof(unsigned);\r\n\r\n /* Map the submission queue ring MAP_PRIVATE */\n map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,\n ring_fd, IORING_OFF_SQ_RING);\n if (map == MAP_FAILED) {\n perror(\u0026quot;mmap\u0026quot;);\n return 1;\n }\r\n\r\n /* We have at least one page. Let\u0026apos;s COW it. */\n *map = 0;\n pause();\n return 0;\n }\n\u0026lt;--- C reproducer ---\u0026gt;\r\n\r\nOn a system with 16 GiB RAM and swap configured:\n # ./iouring \u0026amp;\n # memhog 16G\n # killall iouring\n[ 301.552930] ------------[ cut here ]------------\n[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100\n[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g\n[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1\n[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4\n[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100\n[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000\n[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282\n[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047\n[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200\n[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000\n[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000\n[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000\n[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000\n[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0\n[ 301.565725] PKRU: 55555554\n[ 301.565944] Call Trace:\n[ 301.566148] \u0026lt;TASK\u0026gt;\n[ 301.566325] ? untrack_pfn+0xf4/0x100\n[ 301.566618] ? __warn+0x81/0x130\n[ 301.566876] ? untrack_pfn+0xf4/0x100\n[ 3\n---truncated---(CVE-2024-35877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: reject new basechain after table flag update\r\n\r\nWhen dormant flag is toggled, hooks are disabled in the commit phase by\niterating over current chains in table (existing and new).\r\n\r\nThe following configuration allows for an inconsistent state:\r\n\r\n add table x\n add chain x y { type filter hook input priority 0; }\n add table x { flags dormant; }\n add chain x w { type filter hook input priority 1; }\r\n\r\nwhich triggers the following warning when trying to unregister chain w\nwhich is already unregistered.\r\n\r\n[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[ 127.322519] Call Trace:\n[ 127.322521] \u0026lt;TASK\u0026gt;\n[ 127.322524] ? __warn+0x9f/0x1a0\n[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260\n[ 127.322537] ? report_bug+0x1b1/0x1e0\n[ 127.322545] ? handle_bug+0x3c/0x70\n[ 127.322552] ? exc_invalid_op+0x17/0x40\n[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20\n[ 127.322563] ? kasan_save_free_info+0x3b/0x60\n[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260\n[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260\n[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260\n[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]\n[ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables]\n[ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables](CVE-2024-35900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux: avoid dereference of garbage after mount failure\r\n\r\nIn case kern_mount() fails and returns an error pointer return in the\nerror branch instead of continuing and dereferencing the error pointer.\r\n\r\nWhile on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: prevent division by zero in blk_rq_stat_sum()\r\n\r\nThe expression dst-\u0026gt;nr_samples + src-\u0026gt;nr_samples may\nhave zero value on overflow. It is necessary to add\na check to avoid division by zero.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-direct: Leak pages on dma_set_decrypted() failure\r\n\r\nOn TDX it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\r\n\r\nDMA could free decrypted/shared pages if dma_set_decrypted() fails. This\nshould be a rare case. Just leak the pages in this case instead of\nfreeing them.(CVE-2024-35939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: Fully protect modes[] with dev-\u0026gt;mode_config.mutex\r\n\r\nThe modes[] array contains pointers to modes on the connectors\u0026apos;\nmode lists, which are protected by dev-\u0026gt;mode_config.mutex.\nThus we need to extend modes[] the same protection or by the\ntime we use it the elements may already be pointing to\nfreed/reused memory.(CVE-2024-35950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations\r\n\r\nCreate subvolume, create snapshot and delete subvolume all use\nbtrfs_subvolume_reserve_metadata() to reserve metadata for the changes\ndone to the parent subvolume\u0026apos;s fs tree, which cannot be mediated in the\nnormal way via start_transaction. When quota groups (squota or qgroups)\nare enabled, this reserves qgroup metadata of type PREALLOC. Once the\noperation is associated to a transaction, we convert PREALLOC to\nPERTRANS, which gets cleared in bulk at the end of the transaction.\r\n\r\nHowever, the error paths of these three operations were not implementing\nthis lifecycle correctly. They unconditionally converted the PREALLOC to\nPERTRANS in a generic cleanup step regardless of errors or whether the\noperation was fully associated to a transaction or not. This resulted in\nerror paths occasionally converting this rsv to PERTRANS without calling\nrecord_root_in_trans successfully, which meant that unless that root got\nrecorded in the transaction by some other thread, the end of the\ntransaction would not free that root\u0026apos;s PERTRANS, leaking it. Ultimately,\nthis resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount\nfor the leaked reservation.\r\n\r\nThe fix is to ensure that every qgroup PREALLOC reservation observes the\nfollowing properties:\r\n\r\n1. any failure before record_root_in_trans is called successfully\n results in freeing the PREALLOC reservation.\n2. after record_root_in_trans, we convert to PERTRANS, and now the\n transaction owns freeing the reservation.\r\n\r\nThis patch enforces those properties on the three operations. Without\nit, generic/269 with squotas enabled at mkfs time would fail in ~5-10\nruns on my system. With this patch, it ran successfully 1000 times in a\nrow.(CVE-2024-35956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ena: Fix incorrect descriptor free behavior\r\n\r\nENA has two types of TX queues:\n- queues which only process TX packets arriving from the network stack\n- queues which only process TX packets forwarded to it by XDP_REDIRECT\n or XDP_TX instructions\r\n\r\nThe ena_free_tx_bufs() cycles through all descriptors in a TX queue\nand unmaps + frees every descriptor that hasn\u0026apos;t been acknowledged yet\nby the device (uncompleted TX transactions).\nThe function assumes that the processed TX queue is necessarily from\nthe first category listed above and ends up using napi_consume_skb()\nfor descriptors belonging to an XDP specific queue.\r\n\r\nThis patch solves a bug in which, in case of a VF reset, the\ndescriptors aren\u0026apos;t freed correctly, leading to crashes.(CVE-2024-35958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Properly link new fs rules into the tree\r\n\r\nPreviously, add_rule_fg would only add newly created rules from the\nhandle into the tree when they had a refcount of 1. On the other hand,\ncreate_flow_handle tries hard to find and reference already existing\nidentical rules instead of creating new ones.\r\n\r\nThese two behaviors can result in a situation where create_flow_handle\n1) creates a new rule and references it, then\n2) in a subsequent step during the same handle creation references it\n again,\nresulting in a rule with a refcount of 2 that is not linked into the\ntree, will have a NULL parent and root and will result in a crash when\nthe flow group is deleted because del_sw_hw_rule, invoked on rule\ndeletion, assumes node-\u0026gt;parent is != NULL.\r\n\r\nThis happened in the wild, due to another bug related to incorrect\nhandling of duplicate pkt_reformat ids, which lead to the code in\ncreate_flow_handle incorrectly referencing a just-added rule in the same\nflow handle, resulting in the problem described above. Full details are\nat [1].\r\n\r\nThis patch changes add_rule_fg to add new rules without parents into\nthe tree, properly initializing them and avoiding the crash. This makes\nit more consistent with how rules are added to an FTE in\ncreate_flow_handle.(CVE-2024-35960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Fix memory leak in hci_req_sync_complete()\r\n\r\nIn \u0026apos;hci_req_sync_complete()\u0026apos;, always free the previous sync\nrequest state before assigning reference to a new one.(CVE-2024-35978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Fix oops during rmmod on single-CPU platforms\r\n\r\nDuring the removal of the idxd driver, registered offline callback is\ninvoked as part of the clean up process. However, on systems with only\none CPU online, no valid target is available to migrate the\nperf context, resulting in a kernel oops:\r\n\r\n BUG: unable to handle page fault for address: 000000000002a2b8\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 1470e1067 P4D 0\n Oops: 0002 [#1] PREEMPT SMP NOPTI\n CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57\n Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023\n RIP: 0010:mutex_lock+0x2e/0x50\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __die+0x24/0x70\n page_fault_oops+0x82/0x160\n do_user_addr_fault+0x65/0x6b0\n __pfx___rdmsr_safe_on_cpu+0x10/0x10\n exc_page_fault+0x7d/0x170\n asm_exc_page_fault+0x26/0x30\n mutex_lock+0x2e/0x50\n mutex_lock+0x1e/0x50\n perf_pmu_migrate_context+0x87/0x1f0\n perf_event_cpu_offline+0x76/0x90 [idxd]\n cpuhp_invoke_callback+0xa2/0x4f0\n __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]\n cpuhp_thread_fun+0x98/0x150\n smpboot_thread_fn+0x27/0x260\n smpboot_thread_fn+0x1af/0x260\n __pfx_smpboot_thread_fn+0x10/0x10\n kthread+0x103/0x140\n __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;TASK\u0026gt;\r\n\r\nFix the issue by preventing the migration of the perf context to an\ninvalid target.(CVE-2024-35989)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/hugetlb: fix missing hugetlb_lock for resv uncharge\r\n\r\nThere is a recent report on UFFDIO_COPY over hugetlb:\r\n\r\nhttps://lore.kernel.org/all/000000000000ee06de0616177560@google.com/\r\n\r\n350:\tlockdep_assert_held(\u0026amp;hugetlb_lock);\r\n\r\nShould be an issue in hugetlb but triggered in an userfault context, where\nit goes into the unlikely path where two threads modifying the resv map\ntogether. Mike has a fix in that path for resv uncharge but it looks like\nthe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()\nwill update the cgroup pointer, so it requires to be called with the lock\nheld.(CVE-2024-36000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: Do not use WQ_MEM_RECLAIM flag for workqueue\r\n\r\nIssue reported by customer during SRIOV testing, call trace:\nWhen both i40e and the i40iw driver are loaded, a warning\nin check_flush_dependency is being triggered. This seems\nto be because of the i40e driver workqueue is allocated with\nthe WQ_MEM_RECLAIM flag, and the i40iw one is not.\r\n\r\nSimilar error was encountered on ice too and it was fixed by\nremoving the flag. Do the same for i40e too.\r\n\r\n[Feb 9 09:08] ------------[ cut here ]------------\n[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is\nflushing !WQ_MEM_RECLAIM infiniband:0x0\n[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966\ncheck_flush_dependency+0x10b/0x120\n[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq\nsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4\nnls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr\nrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma\nintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif\nisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal\nintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core\niTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore\nioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich\nintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad\nxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe\ndrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel\nlibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror\ndm_region_hash dm_log dm_mod fuse\n[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not\ntainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1\n[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS\nSE5C620.86B.02.01.0013.121520200651 12/15/2020\n[ +0.000001] Workqueue: i40e i40e_service_task [i40e]\n[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120\n[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48\n81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd\nff \u0026lt;0f\u0026gt; 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90\n[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282\n[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:\n0000000000000027\n[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:\nffff94d47f620bc0\n[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:\n00000000ffff7fff\n[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:\nffff94c5451ea180\n[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:\nffff94c5f1330ab0\n[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)\nknlGS:0000000000000000\n[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:\n00000000007706f0\n[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ +0.000001] PKRU: 55555554\n[ +0.000001] Call Trace:\n[ +0.000001] \u0026lt;TASK\u0026gt;\n[ +0.000002] ? __warn+0x80/0x130\n[ +0.000003] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] ? report_bug+0x195/0x1a0\n[ +0.000005] ? handle_bug+0x3c/0x70\n[ +0.000003] ? exc_invalid_op+0x14/0x70\n[ +0.000002] ? asm_exc_invalid_op+0x16/0x20\n[ +0.000006] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] ? check_flush_dependency+0x10b/0x120\n[ +0.000002] __flush_workqueue+0x126/0x3f0\n[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]\n[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]\n[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]\n[ +0.000020] i40iw_close+0x4b/0x90 [irdma]\n[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]\n[ +0.000035] i40e_service_task+0x126/0x190 [i40e]\n[ +0.000024] process_one_work+0x174/0x340\n[ +0.000003] worker_th\n---truncated---(CVE-2024-36004)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmlxsw: spectrum_acl_tcam: Fix warning during rehash\r\n\r\nAs previously explained, the rehash delayed work migrates filters from\none region to another. This is done by iterating over all chunks (all\nthe filters with the same priority) in the region and in each chunk\niterating over all the filters.\r\n\r\nWhen the work runs out of credits it stores the current chunk and entry\nas markers in the per-work context so that it would know where to resume\nthe migration from the next time the work is scheduled.\r\n\r\nUpon error, the chunk marker is reset to NULL, but without resetting the\nentry markers despite being relative to it. This can result in migration\nbeing resumed from an entry that does not belong to the chunk being\nmigrated. In turn, this will eventually lead to a chunk being iterated\nover as if it is an entry. Because of how the two structures happen to\nbe defined, this does not lead to KASAN splats, but to warnings such as\n[1].\r\n\r\nFix by creating a helper that resets all the markers and call it from\nall the places the currently only reset the chunk marker. For good\nmeasures also call it when starting a completely new rehash. Add a\nwarning to avoid future cases.\r\n\r\n[1]\nWARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0\nModules linked in:\nCPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_afk_encode+0x242/0x2f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n \u0026lt;/TASK\u0026gt;(CVE-2024-36007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppdev: Add an error check in register_device\r\n\r\nIn register_device, the return value of ida_simple_get is unchecked,\nin witch ida_simple_get will use an invalid index value.\r\n\r\nTo address this issue, index should be checked after ida_simple_get. When\nthe index value is abnormal, a warning message should be printed, the port\nshould be dropped, and the value should be recorded.(CVE-2024-36015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: core: delete incorrect free in pinctrl_enable()\r\n\r\nThe \u0026quot;pctldev\u0026quot; struct is allocated in devm_pinctrl_register_and_init().\nIt\u0026apos;s a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),\nso freeing it in pinctrl_enable() will lead to a double free.\r\n\r\nThe devm_pinctrl_dev_release() function frees the pindescs and destroys\nthe mutex as well.(CVE-2024-36940)",
"id": "OESA-2024-1694",
"modified": "2026-08-06T11:07:09Z",
"published": "2024-06-07T11:07:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47356"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47370"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47427"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48689"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52654"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52669"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52677"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52699"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52750"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52759"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52774"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52796"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52798"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52799"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52814"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52826"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52831"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52832"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52836"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52864"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52871"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26833"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27401"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27413"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27415"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35822"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35855"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35877"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35904"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35925"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35939"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35978"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35989"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36940"
}
],
"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-2021-47265",
"CVE-2021-47356",
"CVE-2021-47370",
"CVE-2021-47427",
"CVE-2021-47489",
"CVE-2022-48689",
"CVE-2023-52654",
"CVE-2023-52669",
"CVE-2023-52677",
"CVE-2023-52696",
"CVE-2023-52699",
"CVE-2023-52750",
"CVE-2023-52752",
"CVE-2023-52753",
"CVE-2023-52756",
"CVE-2023-52759",
"CVE-2023-52774",
"CVE-2023-52789",
"CVE-2023-52795",
"CVE-2023-52796",
"CVE-2023-52798",
"CVE-2023-52799",
"CVE-2023-52800",
"CVE-2023-52802",
"CVE-2023-52814",
"CVE-2023-52819",
"CVE-2023-52826",
"CVE-2023-52831",
"CVE-2023-52832",
"CVE-2023-52836",
"CVE-2023-52838",
"CVE-2023-52864",
"CVE-2023-52865",
"CVE-2023-52871",
"CVE-2023-52875",
"CVE-2023-52878",
"CVE-2024-26833",
"CVE-2024-26877",
"CVE-2024-26934",
"CVE-2024-27020",
"CVE-2024-27399",
"CVE-2024-27401",
"CVE-2024-27413",
"CVE-2024-27415",
"CVE-2024-35789",
"CVE-2024-35808",
"CVE-2024-35822",
"CVE-2024-35823",
"CVE-2024-35840",
"CVE-2024-35855",
"CVE-2024-35877",
"CVE-2024-35900",
"CVE-2024-35904",
"CVE-2024-35925",
"CVE-2024-35939",
"CVE-2024-35950",
"CVE-2024-35956",
"CVE-2024-35958",
"CVE-2024-35960",
"CVE-2024-35978",
"CVE-2024-35989",
"CVE-2024-36000",
"CVE-2024-36004",
"CVE-2024-36007",
"CVE-2024-36015",
"CVE-2024-36940"
]
}
OESA-2024-1941 (CVE-2021-47205)
Vulnerability from osv_openeuler – Published: 2024-08-02 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: Unregister clocks/resets when unbinding
Currently, unbinding a CCU driver unmaps the device's MMIO region, while leaving its clocks/resets and their providers registered. This can cause a page fault later when some clock operation tries to perform MMIO. Fix this by separating the CCU initialization from the memory allocation, and then using a devres callback to unregister the clocks and resets.
This also fixes a memory leak of the struct ccu_reset, and uses the
correct owner (the specific platform driver) for the clocks and resets.
Early OF clock providers are never unregistered, and limited error handling is possible, so they are mostly unchanged. The error reporting is made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)
In the Linux kernel, the following vulnerability has been resolved:
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR
In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
Then the data_vault_read() got NULL point dereference problem when accessing the 0x10 value in data_vault.
[ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or NULL value in data_vault.(CVE-2022-48703)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Avoid overwriting the copies of clcsock callback functions
The callback functions of clcsock will be saved and replaced during the fallback. But if the fallback happens more than once, then the copies of these callback functions will be overwritten incorrectly, resulting in a loop call issue:
clcsk->sk_error_report |- smc_fback_error_report() <------------------------------| |- smc_fback_forward_wakeup() | (loop) |- clcsock_callback() (incorrectly overwritten) | |- smc->clcsk_error_report() ------------------|
So this patch fixes the issue by saving these function pointers only once in the fallback and avoiding overwriting.(CVE-2022-48780)
In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr
This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak.(CVE-2022-48859)
In the Linux kernel, the following vulnerability has been resolved:
of: Fix double free in of_parse_phandle_with_args_map
In of_parse_phandle_with_args_map() the inner loop that iterates through the map entries calls of_node_put(new) to free the reference acquired by the previous iteration of the inner loop. This assumes that the value of "new" is NULL on the first iteration of the inner loop.
Make sure that this is true in all iterations of the outer loop by setting "new" to NULL after its value is assigned to "cur".
Extend the unittest to detect the double free and add an additional test case that actually triggers this path.(CVE-2023-52679)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: do not free live element
Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:
add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms
1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one element that share the same key.
This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.
The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer).
Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element.
v2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence.
nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called.(CVE-2024-26925)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.
[..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....]
Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: fix node id validation
While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to:
BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node.
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: clear BM pool before initialization
Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue.(CVE-2024-35837)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: flush pending destroy work before exit_net release
Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue.
The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [ 1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ? __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK>
[ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750] __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [ 1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] _syssendmsg+0x4d4/0x510 [ 1360.548953] _sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ 1360.548994] Freed by task 192222: [ 1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036] __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [ 1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d
(gdb) list *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list); 11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356 nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat ---truncated---(CVE-2024-35899)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Skip do PCI error slot reset during RAS recovery
Why: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] <TASK> [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [ 560.872293] ? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [ 560.885532] ? asm_exc_general_protection+0x27/0x30 [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] process_one_work+0x228/0x3d0 How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.(CVE-2024-35931)
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: fix uninitialized values during inode evict
If an iget fails due to not being able to retrieve information from the server then the inode structure is only partially initialized. When the inode gets evicted, references to uninitialized structures (like fscache cookies) were being made.
This patch checks for a bad_inode before doing anything other than clearing the inode from the cache. Since the inode is bad, it shouldn't have any state associated with it that needs to be written back (and there really isn't a way to complete those anyways).(CVE-2024-36923)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below):
kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 </TASK>
This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state.
Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state.(CVE-2024-37078)
In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate().
Fix this bug add a check of mhdp_state->current_mode.(CVE-2024-38548)
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: add a proper sanity check for endpoints
Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2].
Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration.
[1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK>
[2] Related syzkaller crashes:(CVE-2024-38567)
In the Linux kernel, the following vulnerability has been resolved:
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)
In the Linux kernel, the following vulnerability has been resolved:
media: i2c: et8ek8: Don't strip remove function when driver is builtin
Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.
This also fixes a W=1 modpost warning:
WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)(CVE-2024-38611)
In the Linux kernel, the following vulnerability has been resolved:
media: stk1160: fix bounds checking in stk1160_copy_video()
The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true.
Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line.
To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes.(CVE-2024-38621)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: Handle err return when savagefb_check_var failed
The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().
Current implementation in raid5d() has a weird dependence:
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)
In the Linux kernel, the following vulnerability has been resolved:
mmc: davinci: Don't strip remove function when driver is builtin
Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally.
This also fixes a W=1 modpost warning:
WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)
In the Linux kernel, the following vulnerability has been resolved:
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference.
lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same.
Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races.
The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions.
BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
io_wq_worker (io_uring/io-wq.c:?)
<snip>
read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
io_wq_enqueue (io_uring/io-wq.c:947)
io_queue_iowq (io_uring/io_uring.c:524)
io_req_task_submit (io_uring/io_uring.c:1511)
io_handle_tw_list (io_uring/io_uring.c:1198)
<snip>
Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm").
These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags.
Also, move create_index to avoid holes in the structure.(CVE-2024-39508)
In the Linux kernel, the following vulnerability has been resolved:
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
__kernel_map_pages() is a debug function which clears the valid bit in page table entry for deallocated pages to detect illegal memory accesses to freed pages.
This function set/clear the valid bit using __set_memory(). __set_memory() acquires init_mm's semaphore, and this operation may sleep. This is problematic, because __kernel_map_pages() can be called in atomic context, and thus is illegal to sleep. An example warning that this causes:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd preempt_count: 2, expected: 0 CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37 Hardware name: riscv-virtio,qemu (DT) Call Trace: [<ffffffff800060dc>] dump_backtrace+0x1c/0x24 [<ffffffff8091ef6e>] show_stack+0x2c/0x38 [<ffffffff8092baf8>] dump_stack_lvl+0x5a/0x72 [<ffffffff8092bb24>] dump_stack+0x14/0x1c [<ffffffff8003b7ac>] __might_resched+0x104/0x10e [<ffffffff8003b7f4>] __might_sleep+0x3e/0x62 [<ffffffff8093276a>] down_write+0x20/0x72 [<ffffffff8000cf00>] __set_memory+0x82/0x2fa [<ffffffff8000d324>] __kernel_map_pages+0x5a/0xd4 [<ffffffff80196cca>] __alloc_pages_bulk+0x3b2/0x43a [<ffffffff8018ee82>] __vmalloc_node_range+0x196/0x6ba [<ffffffff80011904>] copy_process+0x72c/0x17ec [<ffffffff80012ab4>] kernel_clone+0x60/0x2fe [<ffffffff80012f62>] kernel_thread+0x82/0xa0 [<ffffffff8003552c>] kthreadd+0x14a/0x1be [<ffffffff809357de>] ret_from_fork+0xe/0x1c
Rewrite this function with apply_to_existing_page_range(). It is fine to not have any locking, because __kernel_map_pages() works with pages being allocated/deallocated and those pages are not changed by anyone else in the meantime.(CVE-2024-40915)
In the Linux kernel, the following vulnerability has been resolved:
iommu: Return right value in iommu_sva_bind_device()
iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer.
In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all.(CVE-2024-40945)
In the Linux kernel, the following vulnerability has been resolved:
ima: Avoid blocking in RCU read-side critical section
A panic happens in ima_match_policy:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 42f873067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ima_match_policy+0x84/0x450 Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ima_get_action+0x22/0x30 process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170 ? alloc_set_pte+0x269/0x4c0 ? prep_new_page+0x81/0x140 ? simple_xattr_get+0x75/0xa0 ? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0 ? files_cgroup_alloc_fd+0x38/0x60 ? __alloc_fd+0xd4/0x250 ? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 entry_SYSCALL_64_after_hwframe+0x65/0xca
Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a RCU read-side critical section which contains kmalloc with GFP_KERNEL. This implies a possible sleep and violates limitations of RCU read-side critical sections on non-PREEMPT systems.
Sleeping within RCU read-side critical section might cause synchronize_rcu() returning early and break RCU protection, allowing a UAF to happen.
The root cause of this issue could be described as follows: | Thread A | Thread B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | synchronize_rcu | | | | kmalloc(GFP_KERNEL)| | | sleep | ==> synchronize_rcu returns early | kfree(entry) | | | | entry = entry->next| ==> UAF happens and entry now becomes NULL (or could be anything). | | entry->action | ==> Accessing entry might cause panic.
To fix this issue, we are converting all kmalloc that is called within RCU read-side critical section to use GFP_ATOMIC.
PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
Use list_for_each_entry_safe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxd_desc_complete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list.(CVE-2024-40956)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible NULL dereference in rt6_probe()
syzbot caught a NULL dereference in rt6_probe() [1]
Bail out if __in6_dev_get() returns NULL.
[1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 find_rr_leaf net/ipv6/route.c:853 [inline] rt6_select net/ipv6/route.c:897 [inline] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [inline] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline] ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)
In the Linux kernel, the following vulnerability has been resolved:
serial: imx: Introduce timeout when waiting on transmitter empty
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock.
In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue.(CVE-2024-40967)
In the Linux kernel, the following vulnerability has been resolved:
ext4: do not create EA inode under buffer lock
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers.(CVE-2024-40972)
In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: replace spin_lock by raw_spin_lock
trace_drop_common() is called with preemption disabled, and it acquires a spin_lock. This is problematic for RT kernels because spin_locks are sleeping locks in this configuration, which causes the following splat:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47 preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 5 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290 irq event stamp: 139909 hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80 hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290 softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170 softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0 Preemption disabled at: [<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0 CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7 Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022 Call Trace: <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520 ...
trace_drop_common() also disables interrupts, but this is a minor issue because we could easily replace it with a local_lock.
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic context.(CVE-2024-40980)
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
Many syzbot reports are pointing to soft lockups in batadv_purge_orig_ref() [1]
Root cause is unknown, but we can avoid spending too much time there and perhaps get more interesting reports.
[1]
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621] Modules linked in: irq event stamp: 6182794 hardirqs last enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271 CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_purge_orig pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline] pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 sp : ffff800099007970 x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000 x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001 x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4 x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0 x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001 x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000 Call trace: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline] arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103 sp : ffff800093a17d30 x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4 x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002 x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000 x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396 x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001 ---truncated---(CVE-2024-40981)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
syzbot found hanging tasks waiting on rtnl_lock [1]
A reproducer is available in the syzbot bug.
When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang.
Return -EAGAIN to prevent infinite looping, while keeping documented behavior.
[1]
INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: events_power_efficient reg_check_chans_work Call Trace: <TASK> context_switch kernel/sched/core.c:5409 [inline] __schedule+0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [inline] reg_leave_invalid_chans net/wireless/reg.c:2466 [inline] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space.(CVE-2024-41011)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"python3-perf-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-debugsource-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-source-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-tools-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-headers-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-tools-devel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"perf-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-devel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm"
],
"src": [
"kernel-5.10.0-136.87.0.168.oe2203sp1.src.rpm"
],
"x86_64": [
"python3-perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-devel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"perf-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-source-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-headers-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-tools-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-tools-devel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"python3-perf-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm",
"kernel-debugsource-5.10.0-136.87.0.168.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.87.0.168.oe2203sp1"
}
],
"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:\r\n\r\nclk: sunxi-ng: Unregister clocks/resets when unbinding\r\n\r\nCurrently, unbinding a CCU driver unmaps the device\u0026apos;s MMIO region, while\nleaving its clocks/resets and their providers registered. This can cause\na page fault later when some clock operation tries to perform MMIO. Fix\nthis by separating the CCU initialization from the memory allocation,\nand then using a devres callback to unregister the clocks and resets.\r\n\r\nThis also fixes a memory leak of the `struct ccu_reset`, and uses the\ncorrect owner (the specific platform driver) for the clocks and resets.\r\n\r\nEarly OF clock providers are never unregistered, and limited error\nhandling is possible, so they are mostly unchanged. The error reporting\nis made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR\r\n\r\nIn some case, the GDDV returns a package with a buffer which has\nzero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).\r\n\r\nThen the data_vault_read() got NULL point dereference problem when\naccessing the 0x10 value in data_vault.\r\n\r\n[ 71.024560] BUG: kernel NULL pointer dereference, address:\n0000000000000010\r\n\r\nThis patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or\nNULL value in data_vault.(CVE-2022-48703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/smc: Avoid overwriting the copies of clcsock callback functions\r\n\r\nThe callback functions of clcsock will be saved and replaced during\nthe fallback. But if the fallback happens more than once, then the\ncopies of these callback functions will be overwritten incorrectly,\nresulting in a loop call issue:\r\n\r\nclcsk-\u0026gt;sk_error_report\n |- smc_fback_error_report() \u0026lt;------------------------------|\n |- smc_fback_forward_wakeup() | (loop)\n |- clcsock_callback() (incorrectly overwritten) |\n |- smc-\u0026gt;clcsk_error_report() ------------------|\r\n\r\nSo this patch fixes the issue by saving these function pointers only\nonce in the fallback and avoiding overwriting.(CVE-2022-48780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr\r\n\r\nThis node pointer is returned by of_find_compatible_node() with\nrefcount incremented. Calling of_node_put() to aovid the refcount leak.(CVE-2022-48859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: Fix double free in of_parse_phandle_with_args_map\r\n\r\nIn of_parse_phandle_with_args_map() the inner loop that\niterates through the map entries calls of_node_put(new)\nto free the reference acquired by the previous iteration\nof the inner loop. This assumes that the value of \u0026quot;new\u0026quot; is\nNULL on the first iteration of the inner loop.\r\n\r\nMake sure that this is true in all iterations of the outer\nloop by setting \u0026quot;new\u0026quot; to NULL after its value is assigned to \u0026quot;cur\u0026quot;.\r\n\r\nExtend the unittest to detect the double free and add an additional\ntest case that actually triggers this path.(CVE-2023-52679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: do not free live element\r\n\r\nPablo reports a crash with large batches of elements with a\nback-to-back add/remove pattern. Quoting Pablo:\r\n\r\n add_elem(\u0026quot;00000000\u0026quot;) timeout 100 ms\n ...\n add_elem(\u0026quot;0000000X\u0026quot;) timeout 100 ms\n del_elem(\u0026quot;0000000X\u0026quot;) \u0026lt;---------------- delete one that was just added\n ...\n add_elem(\u0026quot;00005000\u0026quot;) timeout 100 ms\r\n\r\n 1) nft_pipapo_remove() removes element 0000000X\n Then, KASAN shows a splat.\r\n\r\nLooking at the remove function there is a chance that we will drop a\nrule that maps to a non-deactivated element.\r\n\r\nRemoval happens in two steps, first we do a lookup for key k and return the\nto-be-removed element and mark it as inactive in the next generation.\nThen, in a second step, the element gets removed from the set/map.\r\n\r\nThe _remove function does not work correctly if we have more than one\nelement that share the same key.\r\n\r\nThis can happen if we insert an element into a set when the set already\nholds an element with same key, but the element mapping to the existing\nkey has timed out or is not active in the next generation.\r\n\r\nIn such case its possible that removal will unmap the wrong element.\nIf this happens, we will leak the non-deactivated element, it becomes\nunreachable.\r\n\r\nThe element that got deactivated (and will be freed later) will\nremain reachable in the set data structure, this can result in\na crash when such an element is retrieved during lookup (stale\npointer).\r\n\r\nAdd a check that the fully matching key does in fact map to the element\nthat we have marked as inactive in the deactivation step.\nIf not, we need to continue searching.\r\n\r\nAdd a bug/warn trap at the end of the function as well, the remove\nfunction must not ever be called with an invisible/unreachable/non-existent\nelement.\r\n\r\nv2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: release mutex after nft_gc_seq_end from abort path\r\n\r\nThe commit mutex should not be released during the critical section\nbetween nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC\nworker could collect expired objects and get the released commit lock\nwithin the same GC sequence.\r\n\r\nnf_tables_module_autoload() temporarily releases the mutex to load\nmodule dependencies, then it goes back to replay the transaction again.\nMove it at the end of the abort phase after nft_gc_seq_end() is called.(CVE-2024-26925)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix mirred deadlock on device recursion\r\n\r\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\r\n\r\n[..... other info removed for brevity....]\n[ 82.890906]\n[ 82.890906] ============================================\n[ 82.890906] WARNING: possible recursive locking detected\n[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W\n[ 82.890906] --------------------------------------------\n[ 82.890906] ping/418 is trying to acquire lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] but task is already holding lock:\n[ 82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] other info that might help us debug this:\n[ 82.890906] Possible unsafe locking scenario:\n[ 82.890906]\n[ 82.890906] CPU0\n[ 82.890906] ----\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906] lock(\u0026amp;sch-\u0026gt;q.lock);\n[ 82.890906]\n[ 82.890906] *** DEADLOCK ***\n[ 82.890906]\n[..... other info removed for brevity....]\r\n\r\nExample setup (eth0-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nAnother example(eth0-\u0026gt;eth1-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth1\r\n\r\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n action mirred egress redirect dev eth0\r\n\r\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndma-mapping: benchmark: fix node id validation\r\n\r\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\r\n\r\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n \u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won\u0026apos;t be bound to a\ncpuset of a given node.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\r\n\r\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\r\n\r\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\r\n\r\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mvpp2: clear BM pool before initialization\r\n\r\nRegister value persist after booting the kernel using\nkexec which results in kernel panic. Thus clear the\nBM pool registers before initialisation to fix the issue.(CVE-2024-35837)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: flush pending destroy work before exit_net release\r\n\r\nSimilar to 2c9f0293280e (\u0026quot;netfilter: nf_tables: flush pending destroy\nwork before netlink notifier\u0026quot;) to address a race between exit_net and\nthe destroy workqueue.\r\n\r\nThe trace below shows an element to be released via destroy workqueue\nwhile exit_net path (triggered via module removal) has already released\nthe set that is used in such transaction.\r\n\r\n[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465\n[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359\n[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]\n[ 1360.547984] Call Trace:\n[ 1360.547991] \u0026lt;TASK\u0026gt;\n[ 1360.547998] dump_stack_lvl+0x53/0x70\n[ 1360.548014] print_report+0xc4/0x610\n[ 1360.548026] ? __virt_addr_valid+0xba/0x160\n[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548176] kasan_report+0xae/0xe0\n[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]\n[ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]\n[ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30\n[ 1360.548591] process_one_work+0x2f1/0x670\n[ 1360.548610] worker_thread+0x4d3/0x760\n[ 1360.548627] ? __pfx_worker_thread+0x10/0x10\n[ 1360.548640] kthread+0x16b/0x1b0\n[ 1360.548653] ? __pfx_kthread+0x10/0x10\n[ 1360.548665] ret_from_fork+0x2f/0x50\n[ 1360.548679] ? __pfx_kthread+0x10/0x10\n[ 1360.548690] ret_from_fork_asm+0x1a/0x30\n[ 1360.548707] \u0026lt;/TASK\u0026gt;\r\n\r\n[ 1360.548719] Allocated by task 192061:\n[ 1360.548726] kasan_save_stack+0x20/0x40\n[ 1360.548739] kasan_save_track+0x14/0x30\n[ 1360.548750] __kasan_kmalloc+0x8f/0xa0\n[ 1360.548760] __kmalloc_node+0x1f1/0x450\n[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables]\n[ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]\n[ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]\n[ 1360.548927] netlink_unicast+0x367/0x4f0\n[ 1360.548935] netlink_sendmsg+0x34b/0x610\n[ 1360.548944] ____sys_sendmsg+0x4d4/0x510\n[ 1360.548953] ___sys_sendmsg+0xc9/0x120\n[ 1360.548961] __sys_sendmsg+0xbe/0x140\n[ 1360.548971] do_syscall_64+0x55/0x120\n[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d\r\n\r\n[ 1360.548994] Freed by task 192222:\n[ 1360.548999] kasan_save_stack+0x20/0x40\n[ 1360.549009] kasan_save_track+0x14/0x30\n[ 1360.549019] kasan_save_free_info+0x3b/0x60\n[ 1360.549028] poison_slab_object+0x100/0x180\n[ 1360.549036] __kasan_slab_free+0x14/0x30\n[ 1360.549042] kfree+0xb6/0x260\n[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables]\n[ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables]\n[ 1360.549221] ops_exit_list+0x50/0xa0\n[ 1360.549229] free_exit_list+0x101/0x140\n[ 1360.549236] unregister_pernet_operations+0x107/0x160\n[ 1360.549245] unregister_pernet_subsys+0x1c/0x30\n[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables]\n[ 1360.549345] __do_sys_delete_module+0x253/0x370\n[ 1360.549352] do_syscall_64+0x55/0x120\n[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d\r\n\r\n(gdb) list *__nft_release_table+0x473\n0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).\n11349 list_for_each_entry_safe(flowtable, nf, \u0026amp;table-\u0026gt;flowtables, list) {\n11350 list_del(\u0026amp;flowtable-\u0026gt;list);\n11351 nft_use_dec(\u0026amp;table-\u0026gt;use);\n11352 nf_tables_flowtable_destroy(flowtable);\n11353 }\n11354 list_for_each_entry_safe(set, ns, \u0026amp;table-\u0026gt;sets, list) {\n11355 list_del(\u0026amp;set-\u0026gt;list);\n11356 nft_use_dec(\u0026amp;table-\u0026gt;use);\n11357 if (set-\u0026gt;flags \u0026amp; (NFT_SET_MAP | NFT_SET_OBJECT))\n11358 nft_map_deactivat\n---truncated---(CVE-2024-35899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Skip do PCI error slot reset during RAS recovery\r\n\r\nWhy:\n The PCI error slot reset maybe triggered after inject ue to UMC multi times, this\n caused system hang.\n [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume\n [ 557.373718] [drm] PCIE GART of 512M enabled.\n [ 557.373722] [drm] PTB located at 0x0000031FED700000\n [ 557.373788] [drm] VRAM is lost due to GPU reset!\n [ 557.373789] [drm] PSP is resuming...\n [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset\n [ 557.547067] [drm] PCI error: detected callback, state(1)!!\n [ 557.547069] [drm] No support for XGMI hive yet...\n [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter\n [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations\n [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered\n [ 557.610492] [drm] PCI error: slot reset callback!!\n ...\n [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!\n [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!\n [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI\n [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu\n [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023\n [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]\n [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]\n [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff \u0026lt;48\u0026gt; 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00\n [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202\n [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0\n [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010\n [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08\n [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000\n [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000\n [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000\n [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0\n [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n [ 560.843444] PKRU: 55555554\n [ 560.846480] Call Trace:\n [ 560.849225] \u0026lt;TASK\u0026gt;\n [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea\n [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea\n [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]\n [ 560.867778] ? show_regs.part.0+0x23/0x29\n [ 560.872293] ? __die_body.cold+0x8/0xd\n [ 560.876502] ? die_addr+0x3e/0x60\n [ 560.880238] ? exc_general_protection+0x1c5/0x410\n [ 560.885532] ? asm_exc_general_protection+0x27/0x30\n [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]\n [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]\n [ 560.904520] process_one_work+0x228/0x3d0\nHow:\n In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected\n all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.(CVE-2024-35931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: fix uninitialized values during inode evict\r\n\r\nIf an iget fails due to not being able to retrieve information\nfrom the server then the inode structure is only partially\ninitialized. When the inode gets evicted, references to\nuninitialized structures (like fscache cookies) were being\nmade.\r\n\r\nThis patch checks for a bad_inode before doing anything other\nthan clearing the inode from the cache. Since the inode is\nbad, it shouldn\u0026apos;t have any state associated with it that needs\nto be written back (and there really isn\u0026apos;t a way to complete\nthose anyways).(CVE-2024-36923)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\r\n\r\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\r\n\r\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u0026lt;0f\u0026gt;\n 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n kthread+0x2f0/0x390\n ret_from_fork+0x4b/0x80\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0026apos;s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\r\n\r\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.(CVE-2024-37078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: bridge: cdns-mhdp8546: Fix possible null pointer dereference\r\n\r\nIn cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is\nassigned to mhdp_state-\u0026gt;current_mode, and there is a dereference of it in\ndrm_mode_set_name(), which will lead to a NULL pointer dereference on\nfailure of drm_mode_duplicate().\r\n\r\nFix this bug add a check of mhdp_state-\u0026gt;current_mode.(CVE-2024-38548)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: carl9170: add a proper sanity check for endpoints\r\n\r\nSyzkaller reports [1] hitting a warning which is caused by presence\nof a wrong endpoint type at the URB sumbitting stage. While there\nwas a check for a specific 4th endpoint, since it can switch types\nbetween bulk and interrupt, other endpoints are trusted implicitly.\nSimilar warning is triggered in a couple of other syzbot issues [2].\r\n\r\nFix the issue by doing a comprehensive check of all endpoints\ntaking into account difference between high- and full-speed\nconfiguration.\r\n\r\n[1] Syzkaller report:\n...\nWARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504\n carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]\n carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]\n carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028\n request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n \u0026lt;/TASK\u0026gt;\r\n\r\n[2] Related syzkaller crashes:(CVE-2024-38567)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmacintosh/via-macii: Fix \u0026quot;BUG: sleeping function called from invalid context\u0026quot;\r\n\r\nThe via-macii ADB driver calls request_irq() after disabling hard\ninterrupts. But disabling interrupts isn\u0026apos;t necessary here because the\nVIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: i2c: et8ek8: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback\nbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets\nunbound (e.g. using sysfs or hotplug), the driver is just removed\nwithout the cleanup being performed. This results in resource leaks. Fix\nit by compiling in the remove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\n\tWARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -\u0026gt; et8ek8_remove (section: .exit.text)(CVE-2024-38611)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\r\n\r\nThe subtract in this condition is reversed. The -\u0026gt;length is the length\nof the buffer. The -\u0026gt;bytesused is how many bytes we have copied thus\nfar. When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value. That means the overflow check is never\ntrue.\r\n\r\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;. Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved. You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\r\n\r\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn. Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbdev: savage: Handle err return when savagefb_check_var failed\r\n\r\nThe commit 04e5eac8f3ab(\u0026quot;fbdev: savage: Error out if pixclock equals zero\u0026quot;)\nchecks the value of pixclock to avoid divide-by-zero error. However\nthe function savagefb_probe doesn\u0026apos;t handle the error return of\nsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING\r\n\r\nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with\nsmall possibility, the root cause is exactly the same as commit\nbed9e27baf52 (\u0026quot;Revert \u0026quot;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\u0026quot;\u0026quot;)\r\n\r\nHowever, Dan reported another hang after that, and junxiao investigated\nthe problem and found out that this is caused by plugged bio can\u0026apos;t issue\nfrom raid5d().\r\n\r\nCurrent implementation in raid5d() has a weird dependence:\r\n\r\n1) md_check_recovery() from raid5d() must hold \u0026apos;reconfig_mutex\u0026apos; to clear\n MD_SB_CHANGE_PENDING;\n2) raid5d() handles IO in a deadloop, until all IO are issued;\n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;\r\n\r\nThis behaviour is introduce before v2.6, and for consequence, if other\ncontext hold \u0026apos;reconfig_mutex\u0026apos;, and md_check_recovery() can\u0026apos;t update\nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until\n\u0026apos;reconfig_mutex\u0026apos; is released.\r\n\r\nRefer to the implementation from raid1 and raid10, fix this problem by\nskipping issue IO if MD_SB_CHANGE_PENDING is still set after\nmd_check_recovery(), daemon thread will be woken up when \u0026apos;reconfig_mutex\u0026apos;\nis released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: davinci: Don\u0026apos;t strip remove function when driver is builtin\r\n\r\nUsing __exit for the remove function results in the remove callback being\ndiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.\nusing sysfs or hotplug), the driver is just removed without the cleanup\nbeing performed. This results in resource leaks. Fix it by compiling in the\nremove callback unconditionally.\r\n\r\nThis also fixes a W=1 modpost warning:\r\n\r\nWARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in\nreference: davinci_mmcsd_driver+0x10 (section: .data) -\u0026gt;\ndavinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nliquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet\r\n\r\nIn lio_vf_rep_copy_packet() pg_info-\u0026gt;page is compared to a NULL value,\nbut then it is unconditionally passed to skb_add_rx_frag() which looks\nstrange and could lead to null pointer dereference.\r\n\r\nlio_vf_rep_copy_packet() call trace looks like:\n\tocteon_droq_process_packets\n\t octeon_droq_fast_process_packets\n\t octeon_droq_dispatch_pkt\n\t octeon_create_recv_info\n\t ...search in the dispatch_list...\n\t -\u0026gt;disp_fn(rdisp-\u0026gt;rinfo, ...)\n\t lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)\nIn this path there is no code which sets pg_info-\u0026gt;page to NULL.\nSo this check looks unneeded and doesn\u0026apos;t solve potential problem.\nBut I guess the author had reason to add a check and I have no such card\nand can\u0026apos;t do real test.\nIn addition, the code in the function liquidio_push_packet() in\nliquidio/lio_core.c does exactly the same.\r\n\r\nBased on this, I consider the most acceptable compromise solution to\nadjust this issue by moving skb_add_rx_frag() into conditional scope.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring/io-wq: Use set_bit() and test_bit() at worker-\u0026gt;flags\r\n\r\nUtilize set_bit() and test_bit() on worker-\u0026gt;flags within io_uring/io-wq\nto address potential data races.\r\n\r\nThe structure io_worker-\u0026gt;flags may be accessed through various data\npaths, leading to concurrency issues. When KCSAN is enabled, it reveals\ndata races occurring in io_worker_handle_work and\nio_wq_activate_free_worker functions.\r\n\r\n\t BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker\n\t write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:\n\t io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)\n\t io_wq_worker (io_uring/io-wq.c:?)\n\u0026lt;snip\u0026gt;\r\n\r\n\t read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:\n\t io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)\n\t io_wq_enqueue (io_uring/io-wq.c:947)\n\t io_queue_iowq (io_uring/io_uring.c:524)\n\t io_req_task_submit (io_uring/io_uring.c:1511)\n\t io_handle_tw_list (io_uring/io_uring.c:1198)\n\u0026lt;snip\u0026gt;\r\n\r\nLine numbers against commit 18daea77cca6 (\u0026quot;Merge tag \u0026apos;for-linus\u0026apos; of\ngit://git.kernel.org/pub/scm/virt/kvm/kvm\u0026quot;).\r\n\r\nThese races involve writes and reads to the same memory location by\ndifferent tasks running on different CPUs. To mitigate this, refactor\nthe code to use atomic operations such as set_bit(), test_bit(), and\nclear_bit() instead of basic \u0026quot;and\u0026quot; and \u0026quot;or\u0026quot; operations. This ensures\nthread-safe manipulation of worker flags.\r\n\r\nAlso, move `create_index` to avoid holes in the structure.(CVE-2024-39508)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nriscv: rewrite __kernel_map_pages() to fix sleeping in invalid context\r\n\r\n__kernel_map_pages() is a debug function which clears the valid bit in page\ntable entry for deallocated pages to detect illegal memory accesses to\nfreed pages.\r\n\r\nThis function set/clear the valid bit using __set_memory(). __set_memory()\nacquires init_mm\u0026apos;s semaphore, and this operation may sleep. This is\nproblematic, because __kernel_map_pages() can be called in atomic context,\nand thus is illegal to sleep. An example warning that this causes:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd\npreempt_count: 2, expected: 0\nCPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37\nHardware name: riscv-virtio,qemu (DT)\nCall Trace:\n[\u0026lt;ffffffff800060dc\u0026gt;] dump_backtrace+0x1c/0x24\n[\u0026lt;ffffffff8091ef6e\u0026gt;] show_stack+0x2c/0x38\n[\u0026lt;ffffffff8092baf8\u0026gt;] dump_stack_lvl+0x5a/0x72\n[\u0026lt;ffffffff8092bb24\u0026gt;] dump_stack+0x14/0x1c\n[\u0026lt;ffffffff8003b7ac\u0026gt;] __might_resched+0x104/0x10e\n[\u0026lt;ffffffff8003b7f4\u0026gt;] __might_sleep+0x3e/0x62\n[\u0026lt;ffffffff8093276a\u0026gt;] down_write+0x20/0x72\n[\u0026lt;ffffffff8000cf00\u0026gt;] __set_memory+0x82/0x2fa\n[\u0026lt;ffffffff8000d324\u0026gt;] __kernel_map_pages+0x5a/0xd4\n[\u0026lt;ffffffff80196cca\u0026gt;] __alloc_pages_bulk+0x3b2/0x43a\n[\u0026lt;ffffffff8018ee82\u0026gt;] __vmalloc_node_range+0x196/0x6ba\n[\u0026lt;ffffffff80011904\u0026gt;] copy_process+0x72c/0x17ec\n[\u0026lt;ffffffff80012ab4\u0026gt;] kernel_clone+0x60/0x2fe\n[\u0026lt;ffffffff80012f62\u0026gt;] kernel_thread+0x82/0xa0\n[\u0026lt;ffffffff8003552c\u0026gt;] kthreadd+0x14a/0x1be\n[\u0026lt;ffffffff809357de\u0026gt;] ret_from_fork+0xe/0x1c\r\n\r\nRewrite this function with apply_to_existing_page_range(). It is fine to\nnot have any locking, because __kernel_map_pages() works with pages being\nallocated/deallocated and those pages are not changed by anyone else in the\nmeantime.(CVE-2024-40915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu: Return right value in iommu_sva_bind_device()\r\n\r\niommu_sva_bind_device() should return either a sva bond handle or an\nERR_PTR value in error cases. Existing drivers (idxd and uacce) only\ncheck the return value with IS_ERR(). This could potentially lead to\na kernel NULL pointer dereference issue if the function returns NULL\ninstead of an error pointer.\r\n\r\nIn reality, this doesn\u0026apos;t cause any problems because iommu_sva_bind_device()\nonly returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.\nIn this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will\nreturn an error, and the device drivers won\u0026apos;t call iommu_sva_bind_device()\nat all.(CVE-2024-40945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nima: Avoid blocking in RCU read-side critical section\r\n\r\nA panic happens in ima_match_policy:\r\n\r\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000010\nPGD 42f873067 P4D 0\nOops: 0000 [#1] SMP NOPTI\nCPU: 5 PID: 1286325 Comm: kubeletmonit.sh\nKdump: loaded Tainted: P\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n BIOS 0.0.0 02/06/2015\nRIP: 0010:ima_match_policy+0x84/0x450\nCode: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39\n 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d\n f2 b9 f4 00 0f 84 9c 01 00 00 \u0026lt;44\u0026gt; 85 73 10 74 ea\n 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f\nRSP: 0018:ff71570009e07a80 EFLAGS: 00010207\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200\nRDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000\nRBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739\nR10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970\nR13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001\nFS: 00007f5195b51740(0000)\nGS:ff3e278b12d40000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ima_get_action+0x22/0x30\n process_measurement+0xb0/0x830\n ? page_add_file_rmap+0x15/0x170\n ? alloc_set_pte+0x269/0x4c0\n ? prep_new_page+0x81/0x140\n ? simple_xattr_get+0x75/0xa0\n ? selinux_file_open+0x9d/0xf0\n ima_file_check+0x64/0x90\n path_openat+0x571/0x1720\n do_filp_open+0x9b/0x110\n ? page_counter_try_charge+0x57/0xc0\n ? files_cgroup_alloc_fd+0x38/0x60\n ? __alloc_fd+0xd4/0x250\n ? do_sys_open+0x1bd/0x250\n do_sys_open+0x1bd/0x250\n do_syscall_64+0x5d/0x1d0\n entry_SYSCALL_64_after_hwframe+0x65/0xca\r\n\r\nCommit c7423dbdbc9e (\u0026quot;ima: Handle -ESTALE returned by\nima_filter_rule_match()\u0026quot;) introduced call to ima_lsm_copy_rule within a\nRCU read-side critical section which contains kmalloc with GFP_KERNEL.\nThis implies a possible sleep and violates limitations of RCU read-side\ncritical sections on non-PREEMPT systems.\r\n\r\nSleeping within RCU read-side critical section might cause\nsynchronize_rcu() returning early and break RCU protection, allowing a\nUAF to happen.\r\n\r\nThe root cause of this issue could be described as follows:\n|\tThread A\t|\tThread B\t|\n|\t\t\t|ima_match_policy\t|\n|\t\t\t| rcu_read_lock\t|\n|ima_lsm_update_rule\t|\t\t\t|\n| synchronize_rcu\t|\t\t\t|\n|\t\t\t| kmalloc(GFP_KERNEL)|\n|\t\t\t| sleep\t\t|\n==\u0026gt; synchronize_rcu returns early\n| kfree(entry)\t\t|\t\t\t|\n|\t\t\t| entry = entry-\u0026gt;next|\n==\u0026gt; UAF happens and entry now becomes NULL (or could be anything).\n|\t\t\t| entry-\u0026gt;action\t|\n==\u0026gt; Accessing entry might cause panic.\r\n\r\nTo fix this issue, we are converting all kmalloc that is called within\nRCU read-side critical section to use GFP_ATOMIC.\r\n\r\n[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list\r\n\r\nUse list_for_each_entry_safe() to allow iterating through the list and\ndeleting the entry in the iteration process. The descriptor is freed via\nidxd_desc_complete() and there\u0026apos;s a slight chance may cause issue for\nthe list iterator when the descriptor is reused by another thread\nwithout it being deleted from the list.(CVE-2024-40956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: prevent possible NULL dereference in rt6_probe()\r\n\r\nsyzbot caught a NULL dereference in rt6_probe() [1]\r\n\r\nBail out if __in6_dev_get() returns NULL.\r\n\r\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]\nCPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]\n RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758\nCode: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19\nRSP: 0018:ffffc900034af070 EFLAGS: 00010203\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000\nRDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c\nRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a\nR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000\nFS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784\n nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496\n __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825\n find_rr_leaf net/ipv6/route.c:853 [inline]\n rt6_select net/ipv6/route.c:897 [inline]\n fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195\n ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231\n pol_lookup_func include/net/ip6_fib.h:616 [inline]\n fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121\n ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]\n ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651\n ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147\n ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250\n rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898\n inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n sock_write_iter+0x4b8/0x5c0 net/socket.c:1160\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x6b6/0x1140 fs/read_write.c:590\n ksys_write+0x1f8/0x260 fs/read_write.c:643\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: imx: Introduce timeout when waiting on transmitter empty\r\n\r\nBy waiting at most 1 second for USR2_TXDC to be set, we avoid a potential\ndeadlock.\r\n\r\nIn case of the timeout, there is not much we can do, so we simply ignore\nthe transmitter state and optimistically try to continue.(CVE-2024-40967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: do not create EA inode under buffer lock\r\n\r\next4_xattr_set_entry() creates new EA inodes while holding buffer lock\non the external xattr block. This is problematic as it nests all the\nallocation locking (which acquires locks on other buffers) under the\nbuffer lock. This can even deadlock when the filesystem is corrupted and\ne.g. quota file is setup to contain xattr block as data block. Move the\nallocation of EA inode out of ext4_xattr_set_entry() into the callers.(CVE-2024-40972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrop_monitor: replace spin_lock by raw_spin_lock\r\n\r\ntrace_drop_common() is called with preemption disabled, and it acquires\na spin_lock. This is problematic for RT kernels because spin_locks are\nsleeping locks in this configuration, which causes the following splat:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n5 locks held by rcuc/47/449:\n #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210\n #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130\n #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210\n #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70\n #4: ff1100086ee07520 (\u0026amp;data-\u0026gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290\nirq event stamp: 139909\nhardirqs last enabled at (139908): [\u0026lt;ffffffffb1df2b33\u0026gt;] _raw_spin_unlock_irqrestore+0x63/0x80\nhardirqs last disabled at (139909): [\u0026lt;ffffffffb19bd03d\u0026gt;] trace_drop_common.constprop.0+0x26d/0x290\nsoftirqs last enabled at (139892): [\u0026lt;ffffffffb07a1083\u0026gt;] __local_bh_enable_ip+0x103/0x170\nsoftirqs last disabled at (139898): [\u0026lt;ffffffffb0909b33\u0026gt;] rcu_cpu_kthread+0x93/0x1f0\nPreemption disabled at:\n[\u0026lt;ffffffffb1de786b\u0026gt;] rt_mutex_slowunlock+0xab/0x2e0\nCPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7\nHardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x8c/0xd0\n dump_stack+0x14/0x20\n __might_resched+0x21e/0x2f0\n rt_spin_lock+0x5e/0x130\n ? trace_drop_common.constprop.0+0xb5/0x290\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_drop_common.constprop.0+0xb5/0x290\n ? preempt_count_sub+0x1c/0xd0\n ? _raw_spin_unlock_irqrestore+0x4a/0x80\n ? __pfx_trace_drop_common.constprop.0+0x10/0x10\n ? rt_mutex_slowunlock+0x26a/0x2e0\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_rt_mutex_slowunlock+0x10/0x10\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_kfree_skb_hit+0x15/0x20\n trace_kfree_skb+0xe9/0x150\n kfree_skb_reason+0x7b/0x110\n skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10\n ? mark_lock.part.0+0x8a/0x520\n...\r\n\r\ntrace_drop_common() also disables interrupts, but this is a minor issue\nbecause we could easily replace it with a local_lock.\r\n\r\nReplace the spin_lock with raw_spin_lock to avoid sleeping in atomic\ncontext.(CVE-2024-40980)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: bypass empty buckets in batadv_purge_orig_ref()\r\n\r\nMany syzbot reports are pointing to soft lockups in\nbatadv_purge_orig_ref() [1]\r\n\r\nRoot cause is unknown, but we can avoid spending too much\ntime there and perhaps get more interesting reports.\r\n\r\n[1]\r\n\r\nwatchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]\nModules linked in:\nirq event stamp: 6182794\n hardirqs last enabled at (6182793): [\u0026lt;ffff8000801dae10\u0026gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (6182794): [\u0026lt;ffff80008ad66a78\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]\n softirqs last enabled at (6182792): [\u0026lt;ffff80008aab71c4\u0026gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]\n softirqs last disabled at (6182790): [\u0026lt;ffff80008aab61dc\u0026gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271\nCPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_purge_orig\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]\n pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388\n lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386\nsp : ffff800099007970\nx29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000\nx26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001\nx23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4\nx20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0\nx17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001\nx14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003\nx11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000\nCall trace:\n __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]\n arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]\n __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]\n _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287\n batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300\n process_one_work+0x694/0x1204 kernel/workqueue.c:2633\n process_scheduled_works kernel/workqueue.c:2706 [inline]\n worker_thread+0x938/0xef4 kernel/workqueue.c:2787\n kthread+0x288/0x310 kernel/kthread.c:388\n ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51\n lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103\nsp : ffff800093a17d30\nx29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4\nx26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002\nx23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000\nx20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396\nx17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001\n---truncated---(CVE-2024-40981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()\r\n\r\nsyzbot found hanging tasks waiting on rtnl_lock [1]\r\n\r\nA reproducer is available in the syzbot bug.\r\n\r\nWhen a request to add multiple actions with the same index is sent, the\nsecond request will block forever on the first request. This holds\nrtnl_lock, and causes tasks to hang.\r\n\r\nReturn -EAGAIN to prevent infinite looping, while keeping documented\nbehavior.\r\n\r\n[1]\r\n\r\nINFO: task kworker/1:0:5088 blocked for more than 143 seconds.\nNot tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000\nWorkqueue: events_power_efficient reg_check_chans_work\nCall Trace:\n\u0026lt;TASK\u0026gt;\ncontext_switch kernel/sched/core.c:5409 [inline]\n__schedule+0xf15/0x5d00 kernel/sched/core.c:6746\n__schedule_loop kernel/sched/core.c:6823 [inline]\nschedule+0xe7/0x350 kernel/sched/core.c:6838\nschedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895\n__mutex_lock_common kernel/locking/mutex.c:684 [inline]\n__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752\nwiphy_lock include/net/cfg80211.h:5953 [inline]\nreg_leave_invalid_chans net/wireless/reg.c:2466 [inline]\nreg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdkfd: don\u0026apos;t allow mapping the MMIO HDP page with large pages\r\n\r\nWe don\u0026apos;t get the right offset in that case. The GPU has\nan unused 4K area of the register BAR space into which you can\nremap registers. We remap the HDP flush registers into this\nspace to allow userspace (CPU or GPU) to flush the HDP when it\nupdates VRAM. However, on systems with \u0026gt;4K pages, we end up\nexposing PAGE_SIZE of MMIO space.(CVE-2024-41011)",
"id": "OESA-2024-1941",
"modified": "2026-08-06T11:07:24Z",
"published": "2024-08-02T11:07:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/en/security/security-bulletins/detail?id=openEuler-SA-2024-1941"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47205"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48703"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52679"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26925"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27010"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34777"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35837"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35931"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38548"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38567"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38607"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39484"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39506"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39508"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40915"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40956"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40960"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40972"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41011"
}
],
"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-2021-47205",
"CVE-2022-48703",
"CVE-2022-48780",
"CVE-2022-48859",
"CVE-2023-52679",
"CVE-2024-26924",
"CVE-2024-26925",
"CVE-2024-27010",
"CVE-2024-34777",
"CVE-2024-35808",
"CVE-2024-35837",
"CVE-2024-35899",
"CVE-2024-35931",
"CVE-2024-36923",
"CVE-2024-37078",
"CVE-2024-38548",
"CVE-2024-38567",
"CVE-2024-38607",
"CVE-2024-38611",
"CVE-2024-38621",
"CVE-2024-39475",
"CVE-2024-39476",
"CVE-2024-39484",
"CVE-2024-39506",
"CVE-2024-39508",
"CVE-2024-40915",
"CVE-2024-40945",
"CVE-2024-40947",
"CVE-2024-40956",
"CVE-2024-40960",
"CVE-2024-40967",
"CVE-2024-40972",
"CVE-2024-40980",
"CVE-2024-40981",
"CVE-2024-40995",
"CVE-2024-41011"
]
}
OESA-2026-1337 (CVE-2024-35808)
Vulnerability from osv_openeuler – Published: 2026-02-13 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
x86: fix user address masking non-canonical speculation issue
It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations.(CVE-2024-50102)
In the Linux kernel, the following vulnerability has been resolved:
genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie
The IOMMU translation for MSI message addresses has been a 2-step process, separated in time:
1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated.
2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.
This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached.
Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up.
However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).
This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs.
Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor.
The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex.(CVE-2025-38062)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: fix data race in show_numa_info()
The following data-race was found in show_numa_info():
================================================================== BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show
read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
value changed: 0x0000008f -> 0x00000000
According to this report,there is a read/write data-race because m->private is accessible to multiple CPUs. To fix this, instead of allocating the heap in proc_vmalloc_init() and passing the heap address to m->private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.
v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag(CVE-2025-38449)
In the Linux kernel, the following vulnerability has been resolved:
iio: common: st_sensors: Fix use of uninitialize device structs
Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device.
This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well.
The issue is reported and traced here: 1
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject duplicate device on updates
A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device.
Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case.
WARNING is hit when unregistering the hook:
[49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible.
As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vc_data is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fast_imageblit(). This bheviour is excepted only when fg_console is equal to requested console which is a visible console and updates screen with invalid struct references in fbcon_putcs().(CVE-2025-38685)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.
irq_exit() __irq_exit_rcu() / in_hardirq() returns false after this / preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() / a bpf prog is hooked on this trace point / __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() / will send a IPI to itself / irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +
neeraj: Apply Frederic's suggested fix for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
mm: slub: avoid wake up kswapd in set_track_prepare
set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock.
Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since slaballoc() has preemption disabled, we mask out GFP_DIRECT_RECLAIM from the flags there.
The oops looks something like:
BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c slaballoc+0xccc kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...(CVE-2025-39843)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()
kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask and always allocate memory using the hardcoded GFP_KERNEL flag. This makes them inconsistent with vmalloc(), which was recently extended to support GFP_NOFS and GFP_NOIO allocations.
Page table allocations performed during shadow population also ignore the external gfp_mask. To preserve the intended semantics of GFP_NOFS and GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate memalloc scope.
xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.
There was a report here https://lkml.kernel.org/r/(CVE-2025-39910)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
syzbot reported the splat below. [0]
The repro does the following:
- Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
- Attach the prog to a SOCKMAP
- Add a socket to the SOCKMAP
- Activate fault injection
- Send data less than cork_bytes
At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.
If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().
Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.
The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.
[0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)
In the Linux kernel, the following vulnerability has been resolved:
x86/vmscape: Add conditional IBPB mitigation
VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.
Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.
This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.
The intent is to integrate and optimize these cases post-embargo.
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-source-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"perf-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"python3-perf-6.6.0-139.0.0.120.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.120.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-139.0.0.120.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-source-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"perf-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"python3-perf-6.6.0-139.0.0.120.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.120.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-139.0.0.120.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\n\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86: fix user address masking non-canonical speculation issue\n\nIt turns out that AMD has a \u0026quot;Meltdown Lite(tm)\u0026quot; issue with non-canonical\naccesses in kernel space. And so using just the high bit to decide\nwhether an access is in user space or kernel space ends up with the good\nold \u0026quot;leak speculative data\u0026quot; if you have the right gadget using the\nresult:\n\n CVE-2020-12965 \u201cTransient Execution of Non-Canonical Accesses\u201c\n\nNow, the kernel surrounds the access with a STAC/CLAC pair, and those\ninstructions end up serializing execution on older Zen architectures,\nwhich closes the speculation window.\n\nBut that was true only up until Zen 5, which renames the AC bit [1].\nThat improves performance of STAC/CLAC a lot, but also means that the\nspeculation window is now open.\n\nNote that this affects not just the new address masking, but also the\nregular valid_user_address() check used by access_ok(), and the asm\nversion of the sign bit check in the get_user() helpers.\n\nIt does not affect put_user() or clear_user() variants, since there\u0026apos;s no\nspeculative result to be used in a gadget for those operations.(CVE-2024-50102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngenirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie\n\nThe IOMMU translation for MSI message addresses has been a 2-step process,\nseparated in time:\n\n 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address\n is stored in the MSI descriptor when an MSI interrupt is allocated.\n\n 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a\n translated message address.\n\nThis has an inherent lifetime problem for the pointer stored in the cookie\nthat must remain valid between the two steps. However, there is no locking\nat the irq layer that helps protect the lifetime. Today, this works under\nthe assumption that the iommu domain is not changed while MSI interrupts\nbeing programmed. This is true for normal DMA API users within the kernel,\nas the iommu domain is attached before the driver is probed and cannot be\nchanged while a driver is attached.\n\nClassic VFIO type1 also prevented changing the iommu domain while VFIO was\nrunning as it does not support changing the \u0026quot;container\u0026quot; after starting up.\n\nHowever, iommufd has improved this so that the iommu domain can be changed\nduring VFIO operation. This potentially allows userspace to directly race\nVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and\nVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).\n\nThis potentially causes both the cookie pointer and the unlocked call to\niommu_get_domain_for_dev() on the MSI translation path to become UAFs.\n\nFix the MSI cookie UAF by removing the cookie pointer. The translated IOVA\naddress is already known during iommu_dma_prepare_msi() and cannot change.\nThus, it can simply be stored as an integer in the MSI descriptor.\n\nThe other UAF related to iommu_get_domain_for_dev() will be addressed in\npatch \u0026quot;iommu: Make iommu_dma_prepare_msi() into a generic operation\u0026quot; by\nusing the IOMMU group mutex.(CVE-2025-38062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix data race in show_numa_info()\n\nThe following data-race was found in show_numa_info():\n\n==================================================================\nBUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show\n\nread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0:\n show_numa_info mm/vmalloc.c:4936 [inline]\n vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nwrite to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1:\n show_numa_info mm/vmalloc.c:4934 [inline]\n vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nvalue changed: 0x0000008f -\u0026gt; 0x00000000\n==================================================================\n\nAccording to this report,there is a read/write data-race because\nm-\u0026gt;private is accessible to multiple CPUs. To fix this, instead of\nallocating the heap in proc_vmalloc_init() and passing the heap address to\nm-\u0026gt;private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gem: Acquire references on GEM handles for framebuffers\n\nA GEM handle can be released while the GEM buffer object is attached\nto a DRM framebuffer. This leads to the release of the dma-buf backing\nthe buffer object, if any. [1] Trying to use the framebuffer in further\nmode-setting operations leads to a segmentation fault. Most easily\nhappens with driver that use shadow planes for vmap-ing the dma-buf\nduring a page flip. An example is shown below.\n\n[ 156.791968] ------------[ cut here ]------------\n[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430\n[...]\n[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430\n[ 157.043420] Call Trace:\n[ 157.045898] \u0026lt;TASK\u0026gt;\n[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710\n[ 157.065567] ? dma_buf_vmap+0x224/0x430\n[ 157.069446] ? __warn.cold+0x58/0xe4\n[ 157.073061] ? dma_buf_vmap+0x224/0x430\n[ 157.077111] ? report_bug+0x1dd/0x390\n[ 157.080842] ? handle_bug+0x5e/0xa0\n[ 157.084389] ? exc_invalid_op+0x14/0x50\n[ 157.088291] ? asm_exc_invalid_op+0x16/0x20\n[ 157.092548] ? dma_buf_vmap+0x224/0x430\n[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230\n[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10\n[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10\n[ 157.110697] drm_gem_shmem_vmap+0x74/0x710\n[ 157.114866] drm_gem_vmap+0xa9/0x1b0\n[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0\n[ 157.123086] drm_gem_fb_vmap+0xab/0x300\n[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10\n[ 157.133032] ? lockdep_init_map_type+0x19d/0x880\n[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0\n[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180\n[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40\n[...]\n[ 157.346424] ---[ end trace 0000000000000000 ]---\n\nAcquiring GEM handles for the framebuffer\u0026apos;s GEM buffer objects prevents\nthis from happening. The framebuffer\u0026apos;s cleanup later puts the handle\nreferences.\n\nCommit 1a148af06000 (\u0026quot;drm/gem-shmem: Use dma_buf from GEM object\ninstance\u0026quot;) triggers the segmentation fault easily by using the dma-buf\nfield more widely. The underlying issue with reference counting has\nbeen present before.\n\nv2:\n- acquire the handle instead of the BO (Christian)\n- fix comment style (Christian)\n- drop the Fixes tag (Christian)\n- rename err_ gotos\n- add missing Link tag(CVE-2025-38449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: common: st_sensors: Fix use of uninitialize device structs\n\nThroughout the various probe functions \u0026amp;indio_dev-\u0026gt;dev is used before it\nis initialized. This caused a kernel panic in st_sensors_power_enable()\nwhen the call to devm_regulator_bulk_get_enable() fails and then calls\ndev_err_probe() with the uninitialized device.\n\nThis seems to only cause a panic with dev_err_probe(), dev_err(),\ndev_warn() and dev_info() don\u0026apos;t seem to cause a panic, but are fixed\nas well.\n\nThe issue is reported and traced here: [1](CVE-2025-38531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject duplicate device on updates\n\nA chain/flowtable update with duplicated devices in the same batch is\npossible. Unfortunately, netdev event path only removes the first\ndevice that is found, leaving unregistered the hook of the duplicated\ndevice.\n\nCheck if a duplicated device exists in the transaction batch, bail out\nwith EEXIST in such case.\n\nWARNING is hit when unregistering the hook:\n\n [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150\n [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full)\n [...]\n [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix vmalloc out-of-bounds write in fast_imageblit\n\nThis issue triggers when a userspace program does an ioctl\nFBIOPUT_CON2FBMAP by passing console number and frame buffer number.\nIdeally this maps console to frame buffer and updates the screen if\nconsole is visible.\n\nAs part of mapping it has to do resize of console according to frame\nbuffer info. if this resize fails and returns from vc_do_resize() and\ncontinues further. At this point console and new frame buffer are mapped\nand sets display vars. Despite failure still it continue to proceed\nupdating the screen at later stages where vc_data is related to previous\nframe buffer and frame buffer info and display vars are mapped to new\nframe buffer and eventully leading to out-of-bounds write in\nfast_imageblit(). This bheviour is excepted only when fg_console is\nequal to requested console which is a visible console and updates screen\nwith invalid struct references in fbcon_putcs().(CVE-2025-38685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix rcu_read_unlock() deadloop due to IRQ work\n\nDuring rcu_read_unlock_special(), if this happens during irq_exit(), we\ncan lockup if an IPI is issued. This is because the IPI itself triggers\nthe irq_exit() path causing a recursive lock up.\n\nThis is precisely what Xiongfeng found when invoking a BPF program on\nthe trace_tick_stop() tracepoint As shown in the trace below. Fix by\nmanaging the irq_work state correctly.\n\nirq_exit()\n __irq_exit_rcu()\n /* in_hardirq() returns false after this */\n preempt_count_sub(HARDIRQ_OFFSET)\n tick_irq_exit()\n tick_nohz_irq_exit()\n\t tick_nohz_stop_sched_tick()\n\t trace_tick_stop() /* a bpf prog is hooked on this trace point */\n\t\t __bpf_trace_tick_stop()\n\t\t bpf_trace_run2()\n\t\t\t rcu_read_unlock_special()\n /* will send a IPI to itself */\n\t\t\t irq_work_queue_on(\u0026amp;rdp-\u0026gt;defer_qs_iw, rdp-\u0026gt;cpu);\n\nA simple reproducer can also be obtained by doing the following in\ntick_irq_exit(). It will hang on boot without the patch:\n\n static inline void tick_irq_exit(void)\n {\n +\trcu_read_lock();\n +\tWRITE_ONCE(current-\u0026gt;rcu_read_unlock_special.b.need_qs, true);\n +\trcu_read_unlock();\n +\n\n[neeraj: Apply Frederic\u0026apos;s suggested fix for PREEMPT_RT](CVE-2025-39744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: avoid wake up kswapd in set_track_prepare\n\nset_track_prepare() can incur lock recursion.\nThe issue is that it is called from hrtimer_start_range_ns\nholding the per_cpu(hrtimer_bases)[n].lock, but when enabled\nCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,\nand try to hold the per_cpu(hrtimer_bases)[n].lock.\n\nAvoid deadlock caused by implicitly waking up kswapd by passing in\nallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the\ndebug_objects_fill_pool() case. Inside stack depot they are processed by\ngfp_nested_mask().\nSince ___slab_alloc() has preemption disabled, we mask out\n__GFP_DIRECT_RECLAIM from the flags there.\n\nThe oops looks something like:\n\nBUG: spinlock recursion on CPU#3, swapper/3/0\n lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3\nHardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)\nCall trace:\nspin_bug+0x0\n_raw_spin_lock_irqsave+0x80\nhrtimer_try_to_cancel+0x94\ntask_contending+0x10c\nenqueue_dl_entity+0x2a4\ndl_server_start+0x74\nenqueue_task_fair+0x568\nenqueue_task+0xac\ndo_activate_task+0x14c\nttwu_do_activate+0xcc\ntry_to_wake_up+0x6c8\ndefault_wake_function+0x20\nautoremove_wake_function+0x1c\n__wake_up+0xac\nwakeup_kswapd+0x19c\nwake_all_kswapds+0x78\n__alloc_pages_slowpath+0x1ac\n__alloc_pages_noprof+0x298\nstack_depot_save_flags+0x6b0\nstack_depot_save+0x14\nset_track_prepare+0x5c\n___slab_alloc+0xccc\n__kmalloc_cache_noprof+0x470\n__set_page_owner+0x2bc\npost_alloc_hook[jt]+0x1b8\nprep_new_page+0x28\nget_page_from_freelist+0x1edc\n__alloc_pages_noprof+0x13c\nalloc_slab_page+0x244\nallocate_slab+0x7c\n___slab_alloc+0x8e8\nkmem_cache_alloc_noprof+0x450\ndebug_objects_fill_pool+0x22c\ndebug_object_activate+0x40\nenqueue_hrtimer[jt]+0xdc\nhrtimer_start_range_ns+0x5f8\n...(CVE-2025-39843)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()\n\nkasan_populate_vmalloc() and its helpers ignore the caller\u0026apos;s gfp_mask and\nalways allocate memory using the hardcoded GFP_KERNEL flag. This makes\nthem inconsistent with vmalloc(), which was recently extended to support\nGFP_NOFS and GFP_NOIO allocations.\n\nPage table allocations performed during shadow population also ignore the\nexternal gfp_mask. To preserve the intended semantics of GFP_NOFS and\nGFP_NOIO, wrap the apply_to_page_range() calls into the appropriate\nmemalloc scope.\n\nxfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.\n\nThere was a report here\nhttps://lkml.kernel.org/r/(CVE-2025-39910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-\u0026gt;cork.\n\nsyzbot reported the splat below. [0]\n\nThe repro does the following:\n\n 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)\n 2. Attach the prog to a SOCKMAP\n 3. Add a socket to the SOCKMAP\n 4. Activate fault injection\n 5. Send data less than cork_bytes\n\nAt 5., the data is carried over to the next sendmsg() as it is\nsmaller than the cork_bytes specified by bpf_msg_cork_bytes().\n\nThen, tcp_bpf_send_verdict() tries to allocate psock-\u0026gt;cork to hold\nthe data, but this fails silently due to fault injection + __GFP_NOWARN.\n\nIf the allocation fails, we need to revert the sk-\u0026gt;sk_forward_alloc\nchange done by sk_msg_alloc().\n\nLet\u0026apos;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate\npsock-\u0026gt;cork.\n\nThe \u0026quot;*copied\u0026quot; also needs to be updated such that a proper error can\nbe returned to the caller, sendmsg. It fails to allocate psock-\u0026gt;cork.\nNothing has been corked so far, so this patch simply sets \u0026quot;*copied\u0026quot;\nto 0.\n\n[0]:\nWARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983\nModules linked in:\nCPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156\nCode: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 \u0026lt;0f\u0026gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc\nRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246\nRAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80\nRDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000\nRBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4\nR10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380\nR13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872\nFS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __sk_destruct+0x86/0x660 net/core/sock.c:2339\n rcu_do_batch kernel/rcu/tree.c:2605 [inline]\n rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861\n handle_softirqs+0x286/0x870 kernel/softirq.c:579\n __do_softirq kernel/softirq.c:613 [inline]\n invoke_softirq kernel/softirq.c:453 [inline]\n __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:696\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/vmscape: Add conditional IBPB mitigation\n\nVMSCAPE is a vulnerability that exploits insufficient branch predictor\nisolation between a guest and a userspace hypervisor (like QEMU). Existing\nmitigations already protect kernel/KVM from a malicious guest. Userspace\ncan additionally be protected by flushing the branch predictors after a\nVMexit.\n\nSince it is the userspace that consumes the poisoned branch predictors,\nconditionally issue an IBPB after a VMexit and before returning to\nuserspace. Workloads that frequently switch between hypervisor and\nuserspace will incur the most overhead from the new IBPB.\n\nThis new IBPB is not integrated with the existing IBPB sites. For\ninstance, a task can use the existing speculation control prctl() to\nget an IBPB at context switch time. With this implementation, the\nIBPB is doubled up: one at context switch and another before running\nuserspace.\n\nThe intent is to integrate and optimize these cases post-embargo.\n\n[ dhansen: elaborate on suboptimal IBPB solution ](CVE-2025-40300)",
"id": "OESA-2026-1337",
"modified": "2026-08-06T11:10:22Z",
"published": "2026-02-13T11:10:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1337"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38383"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40300"
}
],
"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-35808",
"CVE-2024-50102",
"CVE-2025-38062",
"CVE-2025-38383",
"CVE-2025-38449",
"CVE-2025-38531",
"CVE-2025-38678",
"CVE-2025-38685",
"CVE-2025-39744",
"CVE-2025-39843",
"CVE-2025-39910",
"CVE-2025-39913",
"CVE-2025-40300"
]
}
OESA-2026-1338 (CVE-2024-35808)
Vulnerability from osv_openeuler – Published: 2026-02-13 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
x86: fix user address masking non-canonical speculation issue
It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations.(CVE-2024-50102)
In the Linux kernel, the following vulnerability has been resolved:
genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie
The IOMMU translation for MSI message addresses has been a 2-step process, separated in time:
1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated.
2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.
This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached.
Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up.
However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).
This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs.
Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor.
The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex.(CVE-2025-38062)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: fix data race in show_numa_info()
The following data-race was found in show_numa_info():
================================================================== BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show
read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
value changed: 0x0000008f -> 0x00000000
According to this report,there is a read/write data-race because m->private is accessible to multiple CPUs. To fix this, instead of allocating the heap in proc_vmalloc_init() and passing the heap address to m->private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.
v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag(CVE-2025-38449)
In the Linux kernel, the following vulnerability has been resolved:
iio: common: st_sensors: Fix use of uninitialize device structs
Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device.
This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well.
The issue is reported and traced here: 1
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject duplicate device on updates
A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device.
Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case.
WARNING is hit when unregistering the hook:
[49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible.
As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vc_data is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fast_imageblit(). This bheviour is excepted only when fg_console is equal to requested console which is a visible console and updates screen with invalid struct references in fbcon_putcs().(CVE-2025-38685)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.
irq_exit() __irq_exit_rcu() / in_hardirq() returns false after this / preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() / a bpf prog is hooked on this trace point / __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() / will send a IPI to itself / irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +
neeraj: Apply Frederic's suggested fix for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
mm: slub: avoid wake up kswapd in set_track_prepare
set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock.
Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since slaballoc() has preemption disabled, we mask out GFP_DIRECT_RECLAIM from the flags there.
The oops looks something like:
BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c slaballoc+0xccc kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...(CVE-2025-39843)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()
kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask and always allocate memory using the hardcoded GFP_KERNEL flag. This makes them inconsistent with vmalloc(), which was recently extended to support GFP_NOFS and GFP_NOIO allocations.
Page table allocations performed during shadow population also ignore the external gfp_mask. To preserve the intended semantics of GFP_NOFS and GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate memalloc scope.
xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.
There was a report here https://lkml.kernel.org/r/(CVE-2025-39910)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
syzbot reported the splat below. [0]
The repro does the following:
- Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
- Attach the prog to a SOCKMAP
- Add a socket to the SOCKMAP
- Activate fault injection
- Send data less than cork_bytes
At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.
If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().
Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.
The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.
[0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)
In the Linux kernel, the following vulnerability has been resolved:
x86/vmscape: Add conditional IBPB mitigation
VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.
Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.
This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.
The intent is to integrate and optimize these cases post-embargo.
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"perf-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.133.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-139.0.0.133.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"perf-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.133.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-139.0.0.133.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\n\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86: fix user address masking non-canonical speculation issue\n\nIt turns out that AMD has a \u0026quot;Meltdown Lite(tm)\u0026quot; issue with non-canonical\naccesses in kernel space. And so using just the high bit to decide\nwhether an access is in user space or kernel space ends up with the good\nold \u0026quot;leak speculative data\u0026quot; if you have the right gadget using the\nresult:\n\n CVE-2020-12965 \u201cTransient Execution of Non-Canonical Accesses\u201c\n\nNow, the kernel surrounds the access with a STAC/CLAC pair, and those\ninstructions end up serializing execution on older Zen architectures,\nwhich closes the speculation window.\n\nBut that was true only up until Zen 5, which renames the AC bit [1].\nThat improves performance of STAC/CLAC a lot, but also means that the\nspeculation window is now open.\n\nNote that this affects not just the new address masking, but also the\nregular valid_user_address() check used by access_ok(), and the asm\nversion of the sign bit check in the get_user() helpers.\n\nIt does not affect put_user() or clear_user() variants, since there\u0026apos;s no\nspeculative result to be used in a gadget for those operations.(CVE-2024-50102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngenirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie\n\nThe IOMMU translation for MSI message addresses has been a 2-step process,\nseparated in time:\n\n 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address\n is stored in the MSI descriptor when an MSI interrupt is allocated.\n\n 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a\n translated message address.\n\nThis has an inherent lifetime problem for the pointer stored in the cookie\nthat must remain valid between the two steps. However, there is no locking\nat the irq layer that helps protect the lifetime. Today, this works under\nthe assumption that the iommu domain is not changed while MSI interrupts\nbeing programmed. This is true for normal DMA API users within the kernel,\nas the iommu domain is attached before the driver is probed and cannot be\nchanged while a driver is attached.\n\nClassic VFIO type1 also prevented changing the iommu domain while VFIO was\nrunning as it does not support changing the \u0026quot;container\u0026quot; after starting up.\n\nHowever, iommufd has improved this so that the iommu domain can be changed\nduring VFIO operation. This potentially allows userspace to directly race\nVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and\nVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).\n\nThis potentially causes both the cookie pointer and the unlocked call to\niommu_get_domain_for_dev() on the MSI translation path to become UAFs.\n\nFix the MSI cookie UAF by removing the cookie pointer. The translated IOVA\naddress is already known during iommu_dma_prepare_msi() and cannot change.\nThus, it can simply be stored as an integer in the MSI descriptor.\n\nThe other UAF related to iommu_get_domain_for_dev() will be addressed in\npatch \u0026quot;iommu: Make iommu_dma_prepare_msi() into a generic operation\u0026quot; by\nusing the IOMMU group mutex.(CVE-2025-38062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix data race in show_numa_info()\n\nThe following data-race was found in show_numa_info():\n\n==================================================================\nBUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show\n\nread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0:\n show_numa_info mm/vmalloc.c:4936 [inline]\n vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nwrite to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1:\n show_numa_info mm/vmalloc.c:4934 [inline]\n vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nvalue changed: 0x0000008f -\u0026gt; 0x00000000\n==================================================================\n\nAccording to this report,there is a read/write data-race because\nm-\u0026gt;private is accessible to multiple CPUs. To fix this, instead of\nallocating the heap in proc_vmalloc_init() and passing the heap address to\nm-\u0026gt;private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gem: Acquire references on GEM handles for framebuffers\n\nA GEM handle can be released while the GEM buffer object is attached\nto a DRM framebuffer. This leads to the release of the dma-buf backing\nthe buffer object, if any. [1] Trying to use the framebuffer in further\nmode-setting operations leads to a segmentation fault. Most easily\nhappens with driver that use shadow planes for vmap-ing the dma-buf\nduring a page flip. An example is shown below.\n\n[ 156.791968] ------------[ cut here ]------------\n[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430\n[...]\n[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430\n[ 157.043420] Call Trace:\n[ 157.045898] \u0026lt;TASK\u0026gt;\n[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710\n[ 157.065567] ? dma_buf_vmap+0x224/0x430\n[ 157.069446] ? __warn.cold+0x58/0xe4\n[ 157.073061] ? dma_buf_vmap+0x224/0x430\n[ 157.077111] ? report_bug+0x1dd/0x390\n[ 157.080842] ? handle_bug+0x5e/0xa0\n[ 157.084389] ? exc_invalid_op+0x14/0x50\n[ 157.088291] ? asm_exc_invalid_op+0x16/0x20\n[ 157.092548] ? dma_buf_vmap+0x224/0x430\n[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230\n[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10\n[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10\n[ 157.110697] drm_gem_shmem_vmap+0x74/0x710\n[ 157.114866] drm_gem_vmap+0xa9/0x1b0\n[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0\n[ 157.123086] drm_gem_fb_vmap+0xab/0x300\n[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10\n[ 157.133032] ? lockdep_init_map_type+0x19d/0x880\n[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0\n[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180\n[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40\n[...]\n[ 157.346424] ---[ end trace 0000000000000000 ]---\n\nAcquiring GEM handles for the framebuffer\u0026apos;s GEM buffer objects prevents\nthis from happening. The framebuffer\u0026apos;s cleanup later puts the handle\nreferences.\n\nCommit 1a148af06000 (\u0026quot;drm/gem-shmem: Use dma_buf from GEM object\ninstance\u0026quot;) triggers the segmentation fault easily by using the dma-buf\nfield more widely. The underlying issue with reference counting has\nbeen present before.\n\nv2:\n- acquire the handle instead of the BO (Christian)\n- fix comment style (Christian)\n- drop the Fixes tag (Christian)\n- rename err_ gotos\n- add missing Link tag(CVE-2025-38449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: common: st_sensors: Fix use of uninitialize device structs\n\nThroughout the various probe functions \u0026amp;indio_dev-\u0026gt;dev is used before it\nis initialized. This caused a kernel panic in st_sensors_power_enable()\nwhen the call to devm_regulator_bulk_get_enable() fails and then calls\ndev_err_probe() with the uninitialized device.\n\nThis seems to only cause a panic with dev_err_probe(), dev_err(),\ndev_warn() and dev_info() don\u0026apos;t seem to cause a panic, but are fixed\nas well.\n\nThe issue is reported and traced here: [1](CVE-2025-38531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject duplicate device on updates\n\nA chain/flowtable update with duplicated devices in the same batch is\npossible. Unfortunately, netdev event path only removes the first\ndevice that is found, leaving unregistered the hook of the duplicated\ndevice.\n\nCheck if a duplicated device exists in the transaction batch, bail out\nwith EEXIST in such case.\n\nWARNING is hit when unregistering the hook:\n\n [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150\n [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full)\n [...]\n [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix vmalloc out-of-bounds write in fast_imageblit\n\nThis issue triggers when a userspace program does an ioctl\nFBIOPUT_CON2FBMAP by passing console number and frame buffer number.\nIdeally this maps console to frame buffer and updates the screen if\nconsole is visible.\n\nAs part of mapping it has to do resize of console according to frame\nbuffer info. if this resize fails and returns from vc_do_resize() and\ncontinues further. At this point console and new frame buffer are mapped\nand sets display vars. Despite failure still it continue to proceed\nupdating the screen at later stages where vc_data is related to previous\nframe buffer and frame buffer info and display vars are mapped to new\nframe buffer and eventully leading to out-of-bounds write in\nfast_imageblit(). This bheviour is excepted only when fg_console is\nequal to requested console which is a visible console and updates screen\nwith invalid struct references in fbcon_putcs().(CVE-2025-38685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix rcu_read_unlock() deadloop due to IRQ work\n\nDuring rcu_read_unlock_special(), if this happens during irq_exit(), we\ncan lockup if an IPI is issued. This is because the IPI itself triggers\nthe irq_exit() path causing a recursive lock up.\n\nThis is precisely what Xiongfeng found when invoking a BPF program on\nthe trace_tick_stop() tracepoint As shown in the trace below. Fix by\nmanaging the irq_work state correctly.\n\nirq_exit()\n __irq_exit_rcu()\n /* in_hardirq() returns false after this */\n preempt_count_sub(HARDIRQ_OFFSET)\n tick_irq_exit()\n tick_nohz_irq_exit()\n\t tick_nohz_stop_sched_tick()\n\t trace_tick_stop() /* a bpf prog is hooked on this trace point */\n\t\t __bpf_trace_tick_stop()\n\t\t bpf_trace_run2()\n\t\t\t rcu_read_unlock_special()\n /* will send a IPI to itself */\n\t\t\t irq_work_queue_on(\u0026amp;rdp-\u0026gt;defer_qs_iw, rdp-\u0026gt;cpu);\n\nA simple reproducer can also be obtained by doing the following in\ntick_irq_exit(). It will hang on boot without the patch:\n\n static inline void tick_irq_exit(void)\n {\n +\trcu_read_lock();\n +\tWRITE_ONCE(current-\u0026gt;rcu_read_unlock_special.b.need_qs, true);\n +\trcu_read_unlock();\n +\n\n[neeraj: Apply Frederic\u0026apos;s suggested fix for PREEMPT_RT](CVE-2025-39744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: avoid wake up kswapd in set_track_prepare\n\nset_track_prepare() can incur lock recursion.\nThe issue is that it is called from hrtimer_start_range_ns\nholding the per_cpu(hrtimer_bases)[n].lock, but when enabled\nCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,\nand try to hold the per_cpu(hrtimer_bases)[n].lock.\n\nAvoid deadlock caused by implicitly waking up kswapd by passing in\nallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the\ndebug_objects_fill_pool() case. Inside stack depot they are processed by\ngfp_nested_mask().\nSince ___slab_alloc() has preemption disabled, we mask out\n__GFP_DIRECT_RECLAIM from the flags there.\n\nThe oops looks something like:\n\nBUG: spinlock recursion on CPU#3, swapper/3/0\n lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3\nHardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)\nCall trace:\nspin_bug+0x0\n_raw_spin_lock_irqsave+0x80\nhrtimer_try_to_cancel+0x94\ntask_contending+0x10c\nenqueue_dl_entity+0x2a4\ndl_server_start+0x74\nenqueue_task_fair+0x568\nenqueue_task+0xac\ndo_activate_task+0x14c\nttwu_do_activate+0xcc\ntry_to_wake_up+0x6c8\ndefault_wake_function+0x20\nautoremove_wake_function+0x1c\n__wake_up+0xac\nwakeup_kswapd+0x19c\nwake_all_kswapds+0x78\n__alloc_pages_slowpath+0x1ac\n__alloc_pages_noprof+0x298\nstack_depot_save_flags+0x6b0\nstack_depot_save+0x14\nset_track_prepare+0x5c\n___slab_alloc+0xccc\n__kmalloc_cache_noprof+0x470\n__set_page_owner+0x2bc\npost_alloc_hook[jt]+0x1b8\nprep_new_page+0x28\nget_page_from_freelist+0x1edc\n__alloc_pages_noprof+0x13c\nalloc_slab_page+0x244\nallocate_slab+0x7c\n___slab_alloc+0x8e8\nkmem_cache_alloc_noprof+0x450\ndebug_objects_fill_pool+0x22c\ndebug_object_activate+0x40\nenqueue_hrtimer[jt]+0xdc\nhrtimer_start_range_ns+0x5f8\n...(CVE-2025-39843)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()\n\nkasan_populate_vmalloc() and its helpers ignore the caller\u0026apos;s gfp_mask and\nalways allocate memory using the hardcoded GFP_KERNEL flag. This makes\nthem inconsistent with vmalloc(), which was recently extended to support\nGFP_NOFS and GFP_NOIO allocations.\n\nPage table allocations performed during shadow population also ignore the\nexternal gfp_mask. To preserve the intended semantics of GFP_NOFS and\nGFP_NOIO, wrap the apply_to_page_range() calls into the appropriate\nmemalloc scope.\n\nxfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.\n\nThere was a report here\nhttps://lkml.kernel.org/r/(CVE-2025-39910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-\u0026gt;cork.\n\nsyzbot reported the splat below. [0]\n\nThe repro does the following:\n\n 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)\n 2. Attach the prog to a SOCKMAP\n 3. Add a socket to the SOCKMAP\n 4. Activate fault injection\n 5. Send data less than cork_bytes\n\nAt 5., the data is carried over to the next sendmsg() as it is\nsmaller than the cork_bytes specified by bpf_msg_cork_bytes().\n\nThen, tcp_bpf_send_verdict() tries to allocate psock-\u0026gt;cork to hold\nthe data, but this fails silently due to fault injection + __GFP_NOWARN.\n\nIf the allocation fails, we need to revert the sk-\u0026gt;sk_forward_alloc\nchange done by sk_msg_alloc().\n\nLet\u0026apos;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate\npsock-\u0026gt;cork.\n\nThe \u0026quot;*copied\u0026quot; also needs to be updated such that a proper error can\nbe returned to the caller, sendmsg. It fails to allocate psock-\u0026gt;cork.\nNothing has been corked so far, so this patch simply sets \u0026quot;*copied\u0026quot;\nto 0.\n\n[0]:\nWARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983\nModules linked in:\nCPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156\nCode: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 \u0026lt;0f\u0026gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc\nRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246\nRAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80\nRDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000\nRBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4\nR10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380\nR13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872\nFS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __sk_destruct+0x86/0x660 net/core/sock.c:2339\n rcu_do_batch kernel/rcu/tree.c:2605 [inline]\n rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861\n handle_softirqs+0x286/0x870 kernel/softirq.c:579\n __do_softirq kernel/softirq.c:613 [inline]\n invoke_softirq kernel/softirq.c:453 [inline]\n __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:696\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/vmscape: Add conditional IBPB mitigation\n\nVMSCAPE is a vulnerability that exploits insufficient branch predictor\nisolation between a guest and a userspace hypervisor (like QEMU). Existing\nmitigations already protect kernel/KVM from a malicious guest. Userspace\ncan additionally be protected by flushing the branch predictors after a\nVMexit.\n\nSince it is the userspace that consumes the poisoned branch predictors,\nconditionally issue an IBPB after a VMexit and before returning to\nuserspace. Workloads that frequently switch between hypervisor and\nuserspace will incur the most overhead from the new IBPB.\n\nThis new IBPB is not integrated with the existing IBPB sites. For\ninstance, a task can use the existing speculation control prctl() to\nget an IBPB at context switch time. With this implementation, the\nIBPB is doubled up: one at context switch and another before running\nuserspace.\n\nThe intent is to integrate and optimize these cases post-embargo.\n\n[ dhansen: elaborate on suboptimal IBPB solution ](CVE-2025-40300)",
"id": "OESA-2026-1338",
"modified": "2026-08-06T11:10:22Z",
"published": "2026-02-13T11:10:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1338"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38383"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40300"
}
],
"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-35808",
"CVE-2024-50102",
"CVE-2025-38062",
"CVE-2025-38383",
"CVE-2025-38449",
"CVE-2025-38531",
"CVE-2025-38678",
"CVE-2025-38685",
"CVE-2025-39744",
"CVE-2025-39843",
"CVE-2025-39910",
"CVE-2025-39913",
"CVE-2025-40300"
]
}
OESA-2026-1339 (CVE-2024-35808)
Vulnerability from osv_openeuler – Published: 2026-02-13 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
md/dm-raid: don't call md_reap_sync_thread() directly
Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.
However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").
Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)
In the Linux kernel, the following vulnerability has been resolved:
x86: fix user address masking non-canonical speculation issue
It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations.(CVE-2024-50102)
In the Linux kernel, the following vulnerability has been resolved:
genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie
The IOMMU translation for MSI message addresses has been a 2-step process, separated in time:
1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated.
2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.
This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached.
Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up.
However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).
This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs.
Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor.
The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex.(CVE-2025-38062)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: eir: Fix possible crashes on eir_create_adv_data
eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.(CVE-2025-38303)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc: fix data race in show_numa_info()
The following data-race was found in show_numa_info():
================================================================== BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show
read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 ....
value changed: 0x0000008f -> 0x00000000
According to this report,there is a read/write data-race because m->private is accessible to multiple CPUs. To fix this, instead of allocating the heap in proc_vmalloc_init() and passing the heap address to m->private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)
In the Linux kernel, the following vulnerability has been resolved:
drm/gem: Acquire references on GEM handles for framebuffers
A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.
[ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]---
Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.
Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.
v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag(CVE-2025-38449)
In the Linux kernel, the following vulnerability has been resolved:
s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again
Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear.
Restore the fix and add a comment.(CVE-2025-38489)
In the Linux kernel, the following vulnerability has been resolved:
iio: common: st_sensors: Fix use of uninitialize device structs
Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device.
This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well.
The issue is reported and traced here: 1
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Avoid stack buffer overflow from kernel cmdline
While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject duplicate device on updates
A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device.
Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case.
WARNING is hit when unregistering the hook:
[49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible.
As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vc_do_resize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vc_data is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fast_imageblit(). This bheviour is excepted only when fg_console is equal to requested console which is a visible console and updates screen with invalid struct references in fbcon_putcs().(CVE-2025-38685)
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - flush misc workqueue during device shutdown
Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded.
Since the driver uses a shared workqueue (qat_misc_wq) across all
devices and owned by intel_qat.ko, a deferred routine from the
device-specific driver may still be pending in the queue. If this
routine executes after the driver is unloaded, it can dereference freed
memory, resulting in a page fault and kernel crash like the following:
BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
pm_bh_handler+0x1d2/0x250 [intel_qat]
process_one_work+0x171/0x340
worker_thread+0x277/0x3a0
kthread+0xf0/0x120
ret_from_fork+0x2d/0x50
To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.
Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.(CVE-2025-39721)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.
irq_exit() __irq_exit_rcu() / in_hardirq() returns false after this / preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() / a bpf prog is hooked on this trace point / __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() / will send a IPI to itself / irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +
neeraj: Apply Frederic's suggested fix for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
rcu: Protect ->defer_qs_iw_pending from data race
On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.
In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.
The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:
BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special
read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0
The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.
This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)
In the Linux kernel, the following vulnerability has been resolved:
cifs: prevent NULL pointer dereference in UTF16 conversion
There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.
This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer.
Found by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)
In the Linux kernel, the following vulnerability has been resolved:
mm: slub: avoid wake up kswapd in set_track_prepare
set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock.
Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since slaballoc() has preemption disabled, we mask out GFP_DIRECT_RECLAIM from the flags there.
The oops looks something like:
BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c slaballoc+0xccc kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...(CVE-2025-39843)
In the Linux kernel, the following vulnerability has been resolved:
mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()
kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask and always allocate memory using the hardcoded GFP_KERNEL flag. This makes them inconsistent with vmalloc(), which was recently extended to support GFP_NOFS and GFP_NOIO allocations.
Page table allocations performed during shadow population also ignore the external gfp_mask. To preserve the intended semantics of GFP_NOFS and GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate memalloc scope.
xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.
There was a report here https://lkml.kernel.org/r/(CVE-2025-39910)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
syzbot reported the splat below. [0]
The repro does the following:
- Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
- Attach the prog to a SOCKMAP
- Add a socket to the SOCKMAP
- Activate fault injection
- Send data less than cork_bytes
At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.
If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().
Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.
The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.
[0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_qfq: Fix null-deref in agg_dequeue
To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c.
To avoid code duplication, the following changes are made:
-
Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function.
-
Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it.
-
Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't leak disconnected dentries on umount
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)
In the Linux kernel, the following vulnerability has been resolved:
x86/vmscape: Add conditional IBPB mitigation
VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.
Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.
This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.
The intent is to integrate and optimize these cases post-embargo.
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"perf-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-139.0.0.133.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"perf-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-139.0.0.133.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-139.0.0.133.oe2403sp2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/dm-raid: don\u0026apos;t call md_reap_sync_thread() directly\n\nCurrently md_reap_sync_thread() is called from raid_message() directly\nwithout holding \u0026apos;reconfig_mutex\u0026apos;, this is definitely unsafe because\nmd_reap_sync_thread() can change many fields that is protected by\n\u0026apos;reconfig_mutex\u0026apos;.\n\nHowever, hold \u0026apos;reconfig_mutex\u0026apos; here is still problematic because this\nwill cause deadlock, for example, commit 130443d60b1b (\u0026quot;md: refactor\nidle/frozen_sync_thread() to fix deadlock\u0026quot;).\n\nFix this problem by using stop_sync_thread() to unregister sync_thread,\nlike md/raid did.(CVE-2024-35808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86: fix user address masking non-canonical speculation issue\n\nIt turns out that AMD has a \u0026quot;Meltdown Lite(tm)\u0026quot; issue with non-canonical\naccesses in kernel space. And so using just the high bit to decide\nwhether an access is in user space or kernel space ends up with the good\nold \u0026quot;leak speculative data\u0026quot; if you have the right gadget using the\nresult:\n\n CVE-2020-12965 \u201cTransient Execution of Non-Canonical Accesses\u201c\n\nNow, the kernel surrounds the access with a STAC/CLAC pair, and those\ninstructions end up serializing execution on older Zen architectures,\nwhich closes the speculation window.\n\nBut that was true only up until Zen 5, which renames the AC bit [1].\nThat improves performance of STAC/CLAC a lot, but also means that the\nspeculation window is now open.\n\nNote that this affects not just the new address masking, but also the\nregular valid_user_address() check used by access_ok(), and the asm\nversion of the sign bit check in the get_user() helpers.\n\nIt does not affect put_user() or clear_user() variants, since there\u0026apos;s no\nspeculative result to be used in a gadget for those operations.(CVE-2024-50102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngenirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie\n\nThe IOMMU translation for MSI message addresses has been a 2-step process,\nseparated in time:\n\n 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address\n is stored in the MSI descriptor when an MSI interrupt is allocated.\n\n 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a\n translated message address.\n\nThis has an inherent lifetime problem for the pointer stored in the cookie\nthat must remain valid between the two steps. However, there is no locking\nat the irq layer that helps protect the lifetime. Today, this works under\nthe assumption that the iommu domain is not changed while MSI interrupts\nbeing programmed. This is true for normal DMA API users within the kernel,\nas the iommu domain is attached before the driver is probed and cannot be\nchanged while a driver is attached.\n\nClassic VFIO type1 also prevented changing the iommu domain while VFIO was\nrunning as it does not support changing the \u0026quot;container\u0026quot; after starting up.\n\nHowever, iommufd has improved this so that the iommu domain can be changed\nduring VFIO operation. This potentially allows userspace to directly race\nVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and\nVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).\n\nThis potentially causes both the cookie pointer and the unlocked call to\niommu_get_domain_for_dev() on the MSI translation path to become UAFs.\n\nFix the MSI cookie UAF by removing the cookie pointer. The translated IOVA\naddress is already known during iommu_dma_prepare_msi() and cannot change.\nThus, it can simply be stored as an integer in the MSI descriptor.\n\nThe other UAF related to iommu_get_domain_for_dev() will be addressed in\npatch \u0026quot;iommu: Make iommu_dma_prepare_msi() into a generic operation\u0026quot; by\nusing the IOMMU group mutex.(CVE-2025-38062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix possible crashes on eir_create_adv_data\n\neir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER\nwithout checking if that would fit.(CVE-2025-38303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix data race in show_numa_info()\n\nThe following data-race was found in show_numa_info():\n\n==================================================================\nBUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show\n\nread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0:\n show_numa_info mm/vmalloc.c:4936 [inline]\n vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nwrite to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1:\n show_numa_info mm/vmalloc.c:4934 [inline]\n vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016\n seq_read_iter+0x373/0xb40 fs/seq_file.c:230\n proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299\n....\n\nvalue changed: 0x0000008f -\u0026gt; 0x00000000\n==================================================================\n\nAccording to this report,there is a read/write data-race because\nm-\u0026gt;private is accessible to multiple CPUs. To fix this, instead of\nallocating the heap in proc_vmalloc_init() and passing the heap address to\nm-\u0026gt;private, vmalloc_info_show() should allocate the heap.(CVE-2025-38383)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gem: Acquire references on GEM handles for framebuffers\n\nA GEM handle can be released while the GEM buffer object is attached\nto a DRM framebuffer. This leads to the release of the dma-buf backing\nthe buffer object, if any. [1] Trying to use the framebuffer in further\nmode-setting operations leads to a segmentation fault. Most easily\nhappens with driver that use shadow planes for vmap-ing the dma-buf\nduring a page flip. An example is shown below.\n\n[ 156.791968] ------------[ cut here ]------------\n[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430\n[...]\n[ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430\n[ 157.043420] Call Trace:\n[ 157.045898] \u0026lt;TASK\u0026gt;\n[ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0\n[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710\n[ 157.065567] ? dma_buf_vmap+0x224/0x430\n[ 157.069446] ? __warn.cold+0x58/0xe4\n[ 157.073061] ? dma_buf_vmap+0x224/0x430\n[ 157.077111] ? report_bug+0x1dd/0x390\n[ 157.080842] ? handle_bug+0x5e/0xa0\n[ 157.084389] ? exc_invalid_op+0x14/0x50\n[ 157.088291] ? asm_exc_invalid_op+0x16/0x20\n[ 157.092548] ? dma_buf_vmap+0x224/0x430\n[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230\n[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10\n[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10\n[ 157.110697] drm_gem_shmem_vmap+0x74/0x710\n[ 157.114866] drm_gem_vmap+0xa9/0x1b0\n[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0\n[ 157.123086] drm_gem_fb_vmap+0xab/0x300\n[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10\n[ 157.133032] ? lockdep_init_map_type+0x19d/0x880\n[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0\n[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180\n[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40\n[...]\n[ 157.346424] ---[ end trace 0000000000000000 ]---\n\nAcquiring GEM handles for the framebuffer\u0026apos;s GEM buffer objects prevents\nthis from happening. The framebuffer\u0026apos;s cleanup later puts the handle\nreferences.\n\nCommit 1a148af06000 (\u0026quot;drm/gem-shmem: Use dma_buf from GEM object\ninstance\u0026quot;) triggers the segmentation fault easily by using the dma-buf\nfield more widely. The underlying issue with reference counting has\nbeen present before.\n\nv2:\n- acquire the handle instead of the BO (Christian)\n- fix comment style (Christian)\n- drop the Fixes tag (Christian)\n- rename err_ gotos\n- add missing Link tag(CVE-2025-38449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again\n\nCommit 7ded842b356d (\u0026quot;s390/bpf: Fix bpf_plt pointer arithmetic\u0026quot;) has\naccidentally removed the critical piece of commit c730fce7c70c\n(\u0026quot;s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL\u0026quot;), causing\nintermittent kernel panics in e.g. perf\u0026apos;s on_switch() prog to reappear.\n\nRestore the fix and add a comment.(CVE-2025-38489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: common: st_sensors: Fix use of uninitialize device structs\n\nThroughout the various probe functions \u0026amp;indio_dev-\u0026gt;dev is used before it\nis initialized. This caused a kernel panic in st_sensors_power_enable()\nwhen the call to devm_regulator_bulk_get_enable() fails and then calls\ndev_err_probe() with the uninitialized device.\n\nThis seems to only cause a panic with dev_err_probe(), dev_err(),\ndev_warn() and dev_info() don\u0026apos;t seem to cause a panic, but are fixed\nas well.\n\nThe issue is reported and traced here: [1](CVE-2025-38531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject duplicate device on updates\n\nA chain/flowtable update with duplicated devices in the same batch is\npossible. Unfortunately, netdev event path only removes the first\ndevice that is found, leaving unregistered the hook of the duplicated\ndevice.\n\nCheck if a duplicated device exists in the transaction batch, bail out\nwith EEXIST in such case.\n\nWARNING is hit when unregistering the hook:\n\n [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150\n [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full)\n [...]\n [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150(CVE-2025-38678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix vmalloc out-of-bounds write in fast_imageblit\n\nThis issue triggers when a userspace program does an ioctl\nFBIOPUT_CON2FBMAP by passing console number and frame buffer number.\nIdeally this maps console to frame buffer and updates the screen if\nconsole is visible.\n\nAs part of mapping it has to do resize of console according to frame\nbuffer info. if this resize fails and returns from vc_do_resize() and\ncontinues further. At this point console and new frame buffer are mapped\nand sets display vars. Despite failure still it continue to proceed\nupdating the screen at later stages where vc_data is related to previous\nframe buffer and frame buffer info and display vars are mapped to new\nframe buffer and eventully leading to out-of-bounds write in\nfast_imageblit(). This bheviour is excepted only when fg_console is\nequal to requested console which is a visible console and updates screen\nwith invalid struct references in fbcon_putcs().(CVE-2025-38685)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - flush misc workqueue during device shutdown\n\nRepeated loading and unloading of a device specific QAT driver, for\nexample qat_4xxx, in a tight loop can lead to a crash due to a\nuse-after-free scenario. This occurs when a power management (PM)\ninterrupt triggers just before the device-specific driver (e.g.,\nqat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains\nloaded.\n\nSince the driver uses a shared workqueue (`qat_misc_wq`) across all\ndevices and owned by intel_qat.ko, a deferred routine from the\ndevice-specific driver may still be pending in the queue. If this\nroutine executes after the driver is unloaded, it can dereference freed\nmemory, resulting in a page fault and kernel crash like the following:\n\n BUG: unable to handle page fault for address: ffa000002e50a01c\n #PF: supervisor read access in kernel mode\n RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]\n Call Trace:\n pm_bh_handler+0x1d2/0x250 [intel_qat]\n process_one_work+0x171/0x340\n worker_thread+0x277/0x3a0\n kthread+0xf0/0x120\n ret_from_fork+0x2d/0x50\n\nTo prevent this, flush the misc workqueue during device shutdown to\nensure that all pending work items are completed before the driver is\nunloaded.\n\nNote: This approach may slightly increase shutdown latency if the\nworkqueue contains jobs from other devices, but it ensures correctness\nand stability.(CVE-2025-39721)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix rcu_read_unlock() deadloop due to IRQ work\n\nDuring rcu_read_unlock_special(), if this happens during irq_exit(), we\ncan lockup if an IPI is issued. This is because the IPI itself triggers\nthe irq_exit() path causing a recursive lock up.\n\nThis is precisely what Xiongfeng found when invoking a BPF program on\nthe trace_tick_stop() tracepoint As shown in the trace below. Fix by\nmanaging the irq_work state correctly.\n\nirq_exit()\n __irq_exit_rcu()\n /* in_hardirq() returns false after this */\n preempt_count_sub(HARDIRQ_OFFSET)\n tick_irq_exit()\n tick_nohz_irq_exit()\n\t tick_nohz_stop_sched_tick()\n\t trace_tick_stop() /* a bpf prog is hooked on this trace point */\n\t\t __bpf_trace_tick_stop()\n\t\t bpf_trace_run2()\n\t\t\t rcu_read_unlock_special()\n /* will send a IPI to itself */\n\t\t\t irq_work_queue_on(\u0026amp;rdp-\u0026gt;defer_qs_iw, rdp-\u0026gt;cpu);\n\nA simple reproducer can also be obtained by doing the following in\ntick_irq_exit(). It will hang on boot without the patch:\n\n static inline void tick_irq_exit(void)\n {\n +\trcu_read_lock();\n +\tWRITE_ONCE(current-\u0026gt;rcu_read_unlock_special.b.need_qs, true);\n +\trcu_read_unlock();\n +\n\n[neeraj: Apply Frederic\u0026apos;s suggested fix for PREEMPT_RT](CVE-2025-39744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special(). This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special(). In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield. This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: prevent NULL pointer dereference in UTF16 conversion\n\nThere can be a NULL pointer dereference bug here. NULL is passed to\n__cifs_sfu_make_node without checks, which passes it unchecked to\ncifs_strndup_to_utf16, which in turn passes it to\ncifs_local_to_utf16_bytes where \u0026apos;*from\u0026apos; is dereferenced, causing a crash.\n\nThis patch adds a check for NULL \u0026apos;src\u0026apos; in cifs_strndup_to_utf16 and\nreturns NULL early to prevent dereferencing NULL pointer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: avoid wake up kswapd in set_track_prepare\n\nset_track_prepare() can incur lock recursion.\nThe issue is that it is called from hrtimer_start_range_ns\nholding the per_cpu(hrtimer_bases)[n].lock, but when enabled\nCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,\nand try to hold the per_cpu(hrtimer_bases)[n].lock.\n\nAvoid deadlock caused by implicitly waking up kswapd by passing in\nallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the\ndebug_objects_fill_pool() case. Inside stack depot they are processed by\ngfp_nested_mask().\nSince ___slab_alloc() has preemption disabled, we mask out\n__GFP_DIRECT_RECLAIM from the flags there.\n\nThe oops looks something like:\n\nBUG: spinlock recursion on CPU#3, swapper/3/0\n lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3\nHardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)\nCall trace:\nspin_bug+0x0\n_raw_spin_lock_irqsave+0x80\nhrtimer_try_to_cancel+0x94\ntask_contending+0x10c\nenqueue_dl_entity+0x2a4\ndl_server_start+0x74\nenqueue_task_fair+0x568\nenqueue_task+0xac\ndo_activate_task+0x14c\nttwu_do_activate+0xcc\ntry_to_wake_up+0x6c8\ndefault_wake_function+0x20\nautoremove_wake_function+0x1c\n__wake_up+0xac\nwakeup_kswapd+0x19c\nwake_all_kswapds+0x78\n__alloc_pages_slowpath+0x1ac\n__alloc_pages_noprof+0x298\nstack_depot_save_flags+0x6b0\nstack_depot_save+0x14\nset_track_prepare+0x5c\n___slab_alloc+0xccc\n__kmalloc_cache_noprof+0x470\n__set_page_owner+0x2bc\npost_alloc_hook[jt]+0x1b8\nprep_new_page+0x28\nget_page_from_freelist+0x1edc\n__alloc_pages_noprof+0x13c\nalloc_slab_page+0x244\nallocate_slab+0x7c\n___slab_alloc+0x8e8\nkmem_cache_alloc_noprof+0x450\ndebug_objects_fill_pool+0x22c\ndebug_object_activate+0x40\nenqueue_hrtimer[jt]+0xdc\nhrtimer_start_range_ns+0x5f8\n...(CVE-2025-39843)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()\n\nkasan_populate_vmalloc() and its helpers ignore the caller\u0026apos;s gfp_mask and\nalways allocate memory using the hardcoded GFP_KERNEL flag. This makes\nthem inconsistent with vmalloc(), which was recently extended to support\nGFP_NOFS and GFP_NOIO allocations.\n\nPage table allocations performed during shadow population also ignore the\nexternal gfp_mask. To preserve the intended semantics of GFP_NOFS and\nGFP_NOIO, wrap the apply_to_page_range() calls into the appropriate\nmemalloc scope.\n\nxfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.\n\nThere was a report here\nhttps://lkml.kernel.org/r/(CVE-2025-39910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-\u0026gt;cork.\n\nsyzbot reported the splat below. [0]\n\nThe repro does the following:\n\n 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)\n 2. Attach the prog to a SOCKMAP\n 3. Add a socket to the SOCKMAP\n 4. Activate fault injection\n 5. Send data less than cork_bytes\n\nAt 5., the data is carried over to the next sendmsg() as it is\nsmaller than the cork_bytes specified by bpf_msg_cork_bytes().\n\nThen, tcp_bpf_send_verdict() tries to allocate psock-\u0026gt;cork to hold\nthe data, but this fails silently due to fault injection + __GFP_NOWARN.\n\nIf the allocation fails, we need to revert the sk-\u0026gt;sk_forward_alloc\nchange done by sk_msg_alloc().\n\nLet\u0026apos;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate\npsock-\u0026gt;cork.\n\nThe \u0026quot;*copied\u0026quot; also needs to be updated such that a proper error can\nbe returned to the caller, sendmsg. It fails to allocate psock-\u0026gt;cork.\nNothing has been corked so far, so this patch simply sets \u0026quot;*copied\u0026quot;\nto 0.\n\n[0]:\nWARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983\nModules linked in:\nCPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156\nCode: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 \u0026lt;0f\u0026gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc\nRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246\nRAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80\nRDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000\nRBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4\nR10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380\nR13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872\nFS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __sk_destruct+0x86/0x660 net/core/sock.c:2339\n rcu_do_batch kernel/rcu/tree.c:2605 [inline]\n rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861\n handle_softirqs+0x286/0x870 kernel/softirq.c:579\n __do_softirq kernel/softirq.c:613 [inline]\n invoke_softirq kernel/softirq.c:453 [inline]\n __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:696\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix null-deref in agg_dequeue\n\nTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)\nwhen cl-\u0026gt;qdisc-\u0026gt;ops-\u0026gt;peek(cl-\u0026gt;qdisc) returns NULL, we check the return\nvalue before using it, similar to the existing approach in sch_hfsc.c.\n\nTo avoid code duplication, the following changes are made:\n\n1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static\ninline function.\n\n2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to\ninclude/net/pkt_sched.h so that sch_qfq can reuse it.\n\n3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/vmscape: Add conditional IBPB mitigation\n\nVMSCAPE is a vulnerability that exploits insufficient branch predictor\nisolation between a guest and a userspace hypervisor (like QEMU). Existing\nmitigations already protect kernel/KVM from a malicious guest. Userspace\ncan additionally be protected by flushing the branch predictors after a\nVMexit.\n\nSince it is the userspace that consumes the poisoned branch predictors,\nconditionally issue an IBPB after a VMexit and before returning to\nuserspace. Workloads that frequently switch between hypervisor and\nuserspace will incur the most overhead from the new IBPB.\n\nThis new IBPB is not integrated with the existing IBPB sites. For\ninstance, a task can use the existing speculation control prctl() to\nget an IBPB at context switch time. With this implementation, the\nIBPB is doubled up: one at context switch and another before running\nuserspace.\n\nThe intent is to integrate and optimize these cases post-embargo.\n\n[ dhansen: elaborate on suboptimal IBPB solution ](CVE-2025-40300)",
"id": "OESA-2026-1339",
"modified": "2026-08-06T11:10:22Z",
"published": "2026-02-13T11:10:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1339"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38062"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38303"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38383"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38449"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38489"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38531"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38685"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39721"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39838"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39843"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39910"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40300"
}
],
"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-35808",
"CVE-2024-50102",
"CVE-2025-38062",
"CVE-2025-38303",
"CVE-2025-38383",
"CVE-2025-38449",
"CVE-2025-38489",
"CVE-2025-38531",
"CVE-2025-38676",
"CVE-2025-38678",
"CVE-2025-38685",
"CVE-2025-39721",
"CVE-2025-39744",
"CVE-2025-39749",
"CVE-2025-39838",
"CVE-2025-39843",
"CVE-2025-39910",
"CVE-2025-39913",
"CVE-2025-40083",
"CVE-2025-40105",
"CVE-2025-40300"
]
}
RHSA-2024:9315
Vulnerability from csaf_redhat - Published: 2024-11-12 09:11 - Updated: 2026-09-27 09:30A flaw was found in the `md/dm-raid` subsystem in the Linux kernel. If `md_reap_sync_thread()` is called directly, it could lead to potential misuse or system instability.
SUSE-SU-2024:2135-1
Vulnerability from csaf_suse - Published: 2024-06-21 11:03 - Updated: 2026-09-20 15:54SUSE-SU-2024:2203-1
Vulnerability from csaf_suse - Published: 2024-06-25 13:04 - Updated: 2026-09-20 15:56SUSE-SU-2024:2973-1
Vulnerability from csaf_suse - Published: 2024-08-20 07:15 - Updated: 2026-09-20 16:03SUSE-SU-2025:20008-1
Vulnerability from csaf_suse - Published: 2025-02-03 08:47 - Updated: 2026-09-20 18:07Sightings
| 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.