linux-kernel - Re: [PATCH] hpfs: add checks for ea addresses

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] [day] [month] [year] [list]

Message-ID: <20250724184317.yglbwckofzou6owk@antoni-VivoBook-ASUSLaptop-X512FAY-K512FA>
Date: Thu, 24 Jul 2025 20:44:16 +0200
From: Antoni Pokusinski <apokusinski01@...il.com>
To: Mikulas Patocka <mpatocka@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	syzbot+fa88eb476e42878f2844@...kaller.appspotmail.com
Subject: Re: [PATCH] hpfs: add checks for ea addresses

On Thu, Jul 24, 2025 at 04:21:47PM +0200, Mikulas Patocka wrote:
> 
> 
> On Tue, 22 Jul 2025, Antoni Pokusinski wrote:
> 
> > > If you get a KASAN warning when using "check=normal" or "check=strict", 
> > > report it and I will fix it; with "check=none" it is not supposed to work.
> > > 
> > > Mikulas
> > > 
> > 
> > I'm just wondering what should be the expected kernel behaviour in the situation where
> > "check=none" and the "ea_offs", "acl_size_s", "ea_size_s" fields of fnode are corrupt?
> > If we assume that in such case running into some undefined behavior (which is accessing
> > an unknown memory area) is alright, then the code does not need any changes.
> > But if we'd like to prevent it, then I think we should always check the extended
> > attribute address regardless of the "check" parameter, as demonstrated
> > in the patch.
> > 
> > Kind regards,
> > Antoni
> 
> There is a trade-off between speed and resiliency. If the user wants 
> maximum speed and uses the filesystem only on trusted input, he can choose 
> "check=none". If the user wants less performance and uses the filesystem 
> on untrusted input, he can select "check=normal" (the default). If the 
> user is modifying the code and wants maximum safeguards, he should select 
> "check=strict" (that will degrade performance significantly, but it will 
> stop the filesystem as soon as possible if something goes wrong).
> 
> I think there is no need to add some middle ground where "check=none" 
> would check some structures and won't check others.
> 
> Mikulas
>

Thanks for the explanation. Yeah I think I agree with your point, I
guess that the patch is not necessary then.

Kind regards,
Antoni