CVE-2022-50530: blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix null pointer dereference in blkmqclearrqmapping()
Our syzkaller report a null pointer dereference, root cause is following:
blkmqallocmapandrqs set->tags[hctxidx] = blkmqallocmapandrqs blkmqallocmapandrqs blkmqallocrqs // failed due to oom allocpagesnode // set->tags[hctxidx] is still NULL blkmqfreerqs drvtags = set->tags[hctxidx]; // null pointer dereference is triggered blkmqclearrqmapping(drvtags, ...)
This is because commit 63064be150e4 ("blk-mq: Add blkmqallocmapandrqs()") merged the two steps:
1) set->tags[hctxidx] = blkmqallocrqmap() 2) blkmqallocrqs(..., set->tags[hctxidx])
into one step:
set->tags[hctxidx] = blkmqallocmapandrqs()
Since tags is not initialized yet in this case, fix the problem by checking if tags is NULL pointer in blkmqclearrqmapping().
Affected Software
Remediation
Event History
Frequently Asked Questions
Under what conditions can this be triggered?
Systems are exposed when the Linux kernel blk-mq request-queue setup encounters an out-of-memory failure while allocating requests. The failure can leave a tags entry unset, after which cleanup may dereference the null entry and cause a denial of service.
What level of access does an attacker need, and what is the impact?
The CVSS vector indicates local access and low privileges are required, with no user interaction. The documented impact is availability only; confidentiality and integrity are not affected.
What does the available fix change?
Apply an available kernel patch. The fix adds a null-pointer check in blk_mq_clear_rq_mapping() so cleanup safely handles an uninitialized tags entry after allocation failure.