ALSA: core: Fix NULL module pointer assignment at card init
In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.219, 5.15.161, 6.1.93, 6.6.33, 6.8.12, 6.9.3
- CVEs
- CVE-2024-38605
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 15:41 UTC · Revision 1
Source evidence
ALSA: core: Fix NULL module pointer assignment at card init
core-osv · Original sourcePublished 19 Jun 2024, 13:48 UTC
In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.
osv:CVE-2024-38605
Kernel
Fixed versions: 5.10.219, 5.15.161, 6.1.93, 6.6.33, 6.8.12, 6.9.3
Complete source record
{
"id": "8a9bf222a6ae49ff79654fe6174b5217b2dc26c6de19f30f1db6f5d43bab1858",
"url": "https://osv.dev/vulnerability/CVE-2024-38605",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "ALSA: core: Fix NULL module pointer assignment at card init",
"summary": "In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b (\"ALSA: core: Warn on empty module\") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. \"MODULE\" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.",
"evidence": "osv:CVE-2024-38605",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.219",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.161",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.93",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.33",
"evidence": "/affected/1/ranges"
},
{
"value": "6.8.12",
"evidence": "/affected/1/ranges"
},
{
"value": "6.9.3",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2024-38605",
"aliases": [
"CVE-2024-38605"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "81033c6b584b44514cbb16fffc26ca29a0fa6270"
},
{
"fixed": "d7ff29a429b56f04783152ad7bbd7233b740e434"
},
{
"fixed": "e7e0ca200772bdb2fdc6d43d32d341e87a36f811"
},
{
"fixed": "e007476725730c1a68387b54b7629486d8a8301e"
},
{
"fixed": "e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92"
},
{
"fixed": "c935e72139e6d523defd60fe875c01eb1f9ea5c5"
},
{
"fixed": "6b8374ee2cabcf034faa34e69a855dc496a9ec12"
},
{
"fixed": "39381fe7394e5eafac76e7e9367e7351138a29c1"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-38605.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.9.0"
},
{
"fixed": "5.10.219"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.161"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.93"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.33"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.8.12"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.9.0"
},
{
"fixed": "6.9.3"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-38605.json"
}
}
],
"modified": "2026-10-28T02:30:36.831187226Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e7351138a29c1",
"https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12",
"https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5",
"https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434",
"https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e",
"https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92",
"https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/38xxx/CVE-2024-38605.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-38605",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/38xxx/CVE-2024-38605.json"
}
},
"related_cves": [
{
"value": "CVE-2024-38605",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 504042,
"published_at": "2024-06-19T13:48:15.769+00:00"
}