| commit | b529d5decc4c785a9339dd7dbc1db6dbb23266c5 | [log] [tgz] |
|---|---|---|
| author | Mike Snitzer <[email protected]> | Mon Apr 17 11:59:56 2023 -0400 |
| committer | Michael Kochera <[email protected]> | Thu Jul 20 02:43:43 2023 +0000 |
| tree | f0f0a65083841493f95606597c15537ade390be3 | |
| parent | 352316ff429940aed85ab7c243ede807568d0ac7 [diff] |
dm ioctl: fix nested locking in table_clear() to remove deadlock concern commit 3d32aaa7e66d5c1479a3c31d6c2c5d45dd0d3b89 upstream. syzkaller found the following problematic rwsem locking (with write lock already held): down_read+0x9d/0x450 kernel/locking/rwsem.c:1509 dm_get_inactive_table+0x2b/0xc0 drivers/md/dm-ioctl.c:773 __dev_status+0x4fd/0x7c0 drivers/md/dm-ioctl.c:844 table_clear+0x197/0x280 drivers/md/dm-ioctl.c:1537 In table_clear, it first acquires a write lock https://elixir.bootlin.com/linux/v6.2/source/drivers/md/dm-ioctl.c#L1520 down_write(&_hash_lock); Then before the lock is released at L1539, there is a path shown above: table_clear -> __dev_status -> dm_get_inactive_table -> down_read https://elixir.bootlin.com/linux/v6.2/source/drivers/md/dm-ioctl.c#L773 down_read(&_hash_lock); It tries to acquire the same read lock again, resulting in the deadlock problem. Fix this by moving table_clear()'s __dev_status() call to after its up_write(&_hash_lock); BUG=b/290186419 TEST=None RELEASE_NOTE=Fix CVE-2023-2269 in the kernel. cos-patch: security-moderate Cc: [email protected] Reported-by: Zheng Zhang <[email protected]> Change-Id: If4153484430b681e1afc6fa248920e8cc65e5fca Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/52410 Reviewed-by: Oleksandr Tymoshenko <[email protected]> Tested-by: Cusky Presubmit Bot <[email protected]>