CVE-2021-46938

CVSS v3.1 7.8 (High)
78% Progress
EPSS 0.04 % (5th)
0.04% Progress
Affected Products 1
Advisories 9

In the Linux kernel, the following vulnerability has been resolved:

dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails

When loading a device-mapper table for a request-based mapped device,
and the allocation/initialization of the blk_mq_tag_set for the device
fails, a following device remove will cause a double free.

E.g. (dmesg):
device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device
device-mapper: ioctl: unable to set up device queue for new table.
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0305e098835de000 TEID: 0305e098835de803
Fault in home space mode while using kernel ASCE.
AS:000000025efe0007 R3:0000000000000024
Oops: 0038 ilc:3 [#1] SMP
Modules linked in: ... lots of modules ...
Supported: Yes, External
CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3
Hardware name: IBM 8561 T01 7I2 (LPAR)
Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000
000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000
000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640
00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8
Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8
000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58
#000000025e368ec4: e3b010000008 ag %r11,0(%r1)
>000000025e368eca: e310b0080004 lg %r1,8(%r11)
000000025e368ed0: a7110001 tmll %r1,1
000000025e368ed4: a7740129 brc 7,25e369126
000000025e368ed8: e320b0080004 lg %r2,8(%r11)
000000025e368ede: b904001b lgr %r1,%r11
Call Trace:
[<000000025e368eca>] kfree+0x42/0x330
[<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8
[<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]
[<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod]
[<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod]
[<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod]
[<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod]
[<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod]
[<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0
[<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40
[<000000025e8c15ac>] system_call+0xd8/0x2c8
Last Breaking-Event-Address:
[<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8
Kernel panic - not syncing: Fatal exception: panic_on_oops

When allocation/initialization of the blk_mq_tag_set fails in
dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer
is not reset to NULL; so when dev_remove() later gets into
dm_mq_cleanup_mapped_device() it sees the pointer and tries to
uninitialize and free it again.

Fix this by setting the pointer to NULL in dm_mq_init_request_queue()
error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().

Weaknesses
CWE-415
Double Free
CVE Status
PUBLISHED
CNA
kernel.org
Published Date
2024-02-27 19:04:05
(6 months ago)
Updated Date
2024-04-10 19:20:55
(5 months ago)

Affected Products

Loading...
Loading...

Configuration #1

    CPE23 From Up To
  Linux Kernel from 4.6.0 version and prior 4.9.269 version cpe:2.3:o:linux:linux_kernel >= 4.6.0 < 4.9.269
  Linux Kernel from 4.10.0 version and prior 4.14.233 version cpe:2.3:o:linux:linux_kernel >= 4.10.0 < 4.14.233
  Linux Kernel from 4.15.0 version and prior 4.19.191 version cpe:2.3:o:linux:linux_kernel >= 4.15.0 < 4.19.191
  Linux Kernel from 4.20.0 version and prior 5.4.118 version cpe:2.3:o:linux:linux_kernel >= 4.20.0 < 5.4.118
  Linux Kernel from 5.5.0 version and prior 5.10.36 version cpe:2.3:o:linux:linux_kernel >= 5.5.0 < 5.10.36
  Linux Kernel from 5.11.0 version and prior 5.11.20 version cpe:2.3:o:linux:linux_kernel >= 5.11.0 < 5.11.20
  Linux Kernel from 5.12.0 version and prior 5.12.3 version cpe:2.3:o:linux:linux_kernel >= 5.12.0 < 5.12.3
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...