iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) KASAN reports: [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 [ 4.703196][ T0] Call Trace: [ 4.706334][ T0] [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) after converting the type of the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for example, when ACPI NUMA is disabled via command line), pxm_to_node() can return %NUMA_NO_NODE (-1). It is valid 'magic' number of NUMA node, but not valid bit number to use in bitops. node_online() eventually descends to test_bit() without checking for the input, assuming it's on caller side (which might be good for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads to a
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.137, 5.15.61, 5.18.18, 5.19.2, 5.4.211
- CVEs
- CVE-2022-50093
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 6 Nov 2026, 18:35 UTC · Revision 1
Source evidence
iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)
core-osv · Original sourcePublished 18 Jun 2025, 11:02 UTC
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) KASAN reports: [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 [ 4.703196][ T0] Call Trace: [ 4.706334][ T0] [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) after converting the type of the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for example, when ACPI NUMA is disabled via command line), pxm_to_node() can return %NUMA_NO_NODE (-1). It is valid 'magic' number of NUMA node, but not valid bit number to use in bitops. node_online() eventually descends to test_bit() without checking for the input, assuming it's on caller side (which might be good for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads to a
osv:CVE-2022-50093
Kernel
Fixed versions: 5.4.211, 5.10.137, 5.15.61, 5.18.18, 5.19.2
Complete source record
{
"id": "fcf9e5419d474d965760709f2f90afe89c8d9bbfd6560dd502e7741b4205cbf3",
"url": "https://osv.dev/vulnerability/CVE-2022-50093",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)",
"summary": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) KASAN reports: [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 [ 4.703196][ T0] Call Trace: [ 4.706334][ T0] [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) after converting the type of the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for example, when ACPI NUMA is disabled via command line), pxm_to_node() can return %NUMA_NO_NODE (-1). It is valid 'magic' number of NUMA node, but not valid bit number to use in bitops. node_online() eventually descends to test_bit() without checking for the input, assuming it's on caller side (which might be good for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads to a",
"evidence": "osv:CVE-2022-50093",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.4.211",
"evidence": "/affected/1/ranges"
},
{
"value": "5.10.137",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.61",
"evidence": "/affected/1/ranges"
},
{
"value": "5.18.18",
"evidence": "/affected/1/ranges"
},
{
"value": "5.19.2",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2022-50093",
"aliases": [
"CVE-2022-50093"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "ee34b32d8c2950f66038c8975747ef9aec855289"
},
{
"fixed": "b12304984654d8e58a2b22ff94c4410906d6267f"
},
{
"fixed": "5659efdadf04b56707d58c1b758df16d2e0eff2c"
},
{
"fixed": "0b4c0003aeda32a600f95df53b2848da8a5aa3fa"
},
{
"fixed": "73ce2046e04ad488cecc66757c36cbe1bdf089d4"
},
{
"fixed": "c2304c50f4d94f56c2e326f25c9dc8cf2ba6f5fa"
},
{
"fixed": "b0b0b77ea611e3088e9523e60860f4f41b62b235"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-50093.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "2.6.33"
},
{
"fixed": "5.4.211"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.10.137"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.61"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "5.18.18"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.19.0"
},
{
"fixed": "5.19.2"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-50093.json"
}
}
],
"modified": "2026-10-28T02:30:48.080855382Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0b4c0003aeda32a600f95df53b2848da8a5aa3fa",
"https://git.kernel.org/stable/c/5659efdadf04b56707d58c1b758df16d2e0eff2c",
"https://git.kernel.org/stable/c/73ce2046e04ad488cecc66757c36cbe1bdf089d4",
"https://git.kernel.org/stable/c/b0b0b77ea611e3088e9523e60860f4f41b62b235",
"https://git.kernel.org/stable/c/b12304984654d8e58a2b22ff94c4410906d6267f",
"https://git.kernel.org/stable/c/c2304c50f4d94f56c2e326f25c9dc8cf2ba6f5fa",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/50xxx/CVE-2022-50093.json",
"https://nvd.nist.gov/vuln/detail/CVE-2022-50093",
"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/2022/50xxx/CVE-2022-50093.json"
}
},
"related_cves": [
{
"value": "CVE-2022-50093",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 515891,
"published_at": "2025-06-18T11:02:31.966+00:00"
}