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: Fri, 5 Apr 2024 16:52:40 +0200
From: Christoph Hellwig <hch@....de>
To: Christian Brauner <brauner@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Amir Goldstein <amir73il@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	syzbot <syzbot+9a5b0ced8b1bfb238b56@...kaller.appspotmail.com>,
	gregkh@...uxfoundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
	tj@...nel.org, valesini@...dex-team.ru, Jan Kara <jack@...e.cz>,
	Miklos Szeredi <miklos@...redi.hu>
Subject: Re: [syzbot] [kernfs?] possible deadlock in kernfs_fop_llseek

On Fri, Apr 05, 2024 at 03:48:20PM +0200, Christian Brauner wrote:
> * There's early_lookup_bdev() which deals with PARTUUID,
>   PARTLABEL, raw device number, and lookup based on /dev. No actual path
>   lookup involved in that.
> 
> * So the only interesting case is lookup_bdev() for /sys/power/suspend.
>   That one takes arbitrary paths. But being realistic for a moment...
>   How many people will specify a device path that's _not_ some variant
>   of /dev/...? IOW, how many people will specify a device path that's
>   not on devtmpfs or a symlink on devtmpfs? Probably almost no one.

That's not the point.  The poins is that trying to do the dumb name
to bdev translation in early_lookup_bdev is wrong.  Distro had and have
their own numbering schemes, and not using them bypasses access
control.  We should never use that at runtime.

> <brauner> So /sys/power/resume does systemd ever write anything other than a /dev/* path in to there?
> <maintainer> Hmm? You never do that? It only accepts devno.
> 
> So that takes away one of the main users of this api. So I really
> suspect that arbitrary device path is unused in practice. Maybe I'm all
> wrong though.

I'm all fine with just accepting a devno and no name.  But I fear it
will break something as someone added it for whatever use case they had
(and we should not have allowed that back then, but that ship has sailed
unfortunately)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ