lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 12 Jun 2023 16:40:09 +0200
From:   Jan Kara <jack@...e.cz>
To:     Wenchao Hao <haowenchao2@...wei.com>
Cc:     Jan Kara <jack@...e.com>, linux-kernel@...r.kernel.org,
        linfeilong@...wei.com
Subject: Re: [PATCH 0/2] Fix out-of-bound access if pagecache of udf device
 is corrupted

On Tue 13-06-23 11:22:52, Wenchao Hao wrote:
> Following steps would cause out-of-bound access and even cause kernel
> panic when using udf:
> 
> dd if=/dev/zero of=udf.img bs=1M count=512
> mkfs.udf udf.img
> mount -o loop -t udf udf.img /mnt
> dd if=/dev/random of=/dev/loop0 bs=512 count=1 seek=128
> umount /mnt
> 
> [if /mnt is mounted on /dev/loop0]
> 
> It is because we did not check if udf_sb_info->s_lvid_bh is valid in
> udf_sb_lvidiu().
> 
> Although it's illegal to write backend device since filesystem has been
> mounted, but we should avoid kernel panic if it happened.

No, it is perfectly valid to crash the kernel if someone writes the buffer
cache of the device while the device is mounted (which your example above
does). There is no practical protection against this because someone could
overwrite the buffer just after the moment you verify its validity. The
only protection would be to lock the buffer for each access and fully
verify validity of the data after each locking but the performance and
maintenance overhead of this is too high to justify. So I'm sorry but I
will not take any patches that try to "fix" situations when someone writes
buffer cache while the filesystem is mounted.

I guess your work is motivated by some syzbot reproducer which was doing
this. Let me work on a kernel option which syzbot can use to not report
these issues.


								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ