]> git.baikalelectronics.ru Git - kernel.git/commit
block: unhash blkdev part inode when the part is deleted
authorMing Lei <ming.lei@redhat.com>
Tue, 13 Dec 2022 07:16:03 +0000 (15:16 +0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 19 Dec 2022 11:24:16 +0000 (12:24 +0100)
commitf9736aad38aeed2ddedd1bbc809afc41c151295e
tree4e497b867b372f0e8f8b4dd5668cff330855501d
parent75b3a1b7fef9e9dd7e931b1fa057fab0dcb25ccf
block: unhash blkdev part inode when the part is deleted

v5.11 changes the blkdev lookup mechanism completely since commit
0f711687d915 ("block: simplify bdev/disk lookup in blkdev_get"),
and small part of the change is to unhash part bdev inode when
deleting partition. Turns out this kind of change does fix one
nasty issue in case of BLOCK_EXT_MAJOR:

1) when one partition is deleted & closed, disk_put_part() is always
called before bdput(bdev), see blkdev_put(); so the part's devt can
be freed & re-used before the inode is dropped

2) then new partition with same devt can be created just before the
inode in 1) is dropped, then the old inode/bdev structurein 1) is
re-used for this new partition, this way causes use-after-free and
kernel panic.

It isn't possible to backport the whole big patchset of "merge struct
block_device and struct hd_struct v4" for addressing this issue.

https://lore.kernel.org/linux-block/20201128161510.347752-1-hch@lst.de/

So fixes it by unhashing part bdev in delete_partition(), and this way
is actually aligned with v5.11+'s behavior.

Backported from the following 5.10.y commit:

5f2f77560591 ("block: unhash blkdev part inode when the part is deleted")

Reported-by: Shiwei Cui <cuishw@inspur.com>
Tested-by: Shiwei Cui <cuishw@inspur.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
block/partition-generic.c