CVE-2022-50084: dm raid: fix address sanitizer warning in raid_status
In the Linux kernel, the following vulnerability has been resolved:
dm raid: fix address sanitizer warning in raid_status
There is this warning when using a kernel with the address sanitizer
and running this testsuite:
https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid
==================================================================
BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
<TASK>
dump_stack_lvl+0x6a/0x9c
print_address_description.constprop.0+0x1f/0x1e0
print_report.cold+0x55/0x244
kasan_report+0xc9/0x100
raid_status+0x1747/0x2820 [dm_raid]
dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]
table_load+0x35c/0x630 [dm_mod]
ctl_ioctl+0x411/0x630 [dm_mod]
dm_ctl_ioctl+0xa/0x10 [dm_mod]
__x64_sys_ioctl+0x12a/0x1a0
do_syscall_64+0x5b/0x80
The warning is caused by reading conf->max_nr_stripes in raid_status. The
code in raid_status reads mddev->private, casts it to struct r5conf and
reads the entry max_nr_stripes.
However, if we have different raid type than 4/5/6, mddev->private
doesn't point to struct r5conf; it may point to struct r0conf, struct
r1conf, struct r10conf or struct mpconf. If we cast a pointer to one
of these structs to struct r5conf, we will be reading invalid memory
and KASAN warns about it.
Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel memory-safety bug in the device-mapper RAID component. Under certain RAID status handling, the kernel can read from the wrong structure and trigger an out-of-bounds read. The source bundle does not state data theft, privilege escalation, denial of service, CVSS, or active exploitation.
Executive priority
Treat as a targeted kernel maintenance item for systems using Linux software RAID features. Urgency is lower than internet-exposed exploited issues, but storage hosts should be patched through normal kernel update cycles.
Technical view
raid_status in dm_raid reads mddev->private as struct r5conf and accesses max_nr_stripes. For RAID types other than 4/5/6, mddev->private may reference other RAID config structures, causing invalid memory reads detected by KASAN. The fix limits r5conf access to RAID 4, 5, or 6.
Likely exposure
Linux systems running affected kernel versions and using device-mapper RAID or LVM RAID paths may be exposed. The evidence shows a local kernel path reached during device-mapper operations; no network exposure is described.
Exploitation context
The bundle reports a KASAN finding during a kernel RAID testsuite, with lvcreate in the call trace. KEV is false, and no cited source claims public exploitation or weaponized use.
Researcher notes
Impact evidence is incomplete. The source describes an out-of-bounds read found by KASAN, not a demonstrated crash, leak, or privilege boundary bypass. Avoid assuming exploitability without additional vendor or upstream analysis.
Mitigation direction
Apply Linux kernel or distribution updates containing the dm_raid raid_status fix.
Prioritize hosts using LVM RAID, device-mapper RAID, or related storage automation.
If updates are unavailable, check vendor guidance before applying operational workarounds.
Track kernel advisory status because the bundle provides no CVSS or impact rating.
Validation and detection
Inventory kernel versions against the affected and fixed stable version information.
Confirm whether dm_raid or LVM RAID functionality is used on target systems.
Verify installed kernel packages include one of the referenced stable fixes.
Review storage test results and kernel logs for KASAN or RAID status warnings.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-50084 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
10Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jun 18, 2025, 11:02 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.