On Thu, 25 Aug 2022, Coly Li wrote:
> Hi folks,
>
> Recently I received a bug report from Intel developers (big thanks), the
> kernel panic is caused by a kernel stack overflow and it seems from a
> recursive dm-table reload.
>
> Here is the simplified process to reproduce the panic, I use three 960GB name SSDs.
>
> 1, create 2 dm devices,
> # echo '0 181065567 linear /dev/nvme2n1 0' | dmsetup create nvme2n1bbm
> # echo '0 196616709 linear /dev/nvme3n1 0' | dmsetup create nvm3n1bbm
>
> 2, create a raid with these dm devices and another nvme SSD,
> # mdadm -C /dev/md0 -l 5 -n 3 /dev/nvme4n1 /dev/dm-0 /dev/dm-1
>
> 3, wait for resync to finish
>
> 4, stop the md array
> # mdadm —manage —stop /dev/md0
>
> 5, reload dm table for dm-0
> # cat dm-table-reload | dmsetup reload /dev/dm-0
> And the content of dm-table-reload is,
> 0 1 linear /dev/dm-0 0
> 1 181065566 linear /dev/dm-0 1
>
> 6, suspend and resume dm-0
> # dmsetup suspend /dev/dm-0
> # dmsetup resume /dev/dm-0
>
> The panic can be reproduced in Linux-v5.3 kernel[1], and it changes to
> silent deadlock after minutes in Linux v6.0-rc2. So the problem should
> still exist in upstream kernel.
>
> My question are,
> 1) Does anyone observe or encounter such panic or deadlock before?
> 2) To permit recursive dm-table reload, is it a bug or just as-designed ?
>
> Thanks in advance.
>
> Coly Li
Hi
I would just say "don't do this".
Note that only root can reload dm table, so there are no security
implications in this. And if someone has root, he can do much more harm
than crashing the system with kernel stack overflow.
Recursive table mappings or very deep non-recursive mappings aren't
supposed to work.
Mikulas
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
