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: <20260109151740.GR21071@suse.cz>
Date: Fri, 9 Jan 2026 16:17:41 +0100
From: David Sterba <dsterba@...e.cz>
To: Qu Wenruo <wqu@...e.com>
Cc: Jiasheng Jiang <jiashengjiangcool@...il.com>, Chris Mason <clm@...com>,
	David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: add missing ASSERT for system space_info in
 reserve_chunk_space

On Fri, Jan 09, 2026 at 10:02:00AM +1030, Qu Wenruo wrote:
> 
> 
> 在 2026/1/9 06:15, Jiasheng Jiang 写道:
> > In reserve_chunk_space(), btrfs_find_space_info() is called to retrieve
> > the space_info for the SYSTEM block group. However, the returned pointer
> > is immediately dereferenced by spin_lock(&info->lock) without validation.
> > 
> > While the SYSTEM space_info is expected to be present during normal
> > operations, direct dereference without checking creates a risk of a
> > null pointer dereference. This deviates from the coding pattern seen
> > in peer functions like btrfs_chunk_alloc() where such returns are
> > validated with an ASSERT.
> > 
> > Add an ASSERT() to ensure the pointer is valid before access, improving
> > code robustness and consistency with the rest of the block-group logic.
> 
> If you know how system chunk works, you must understand without a system 
> chunk a btrfs will never be mounted.
> 
> The ASSERT() looks unnecessary to me.

Agreed. I tried to look for justification or an assertion pattern we
might have yet incomplete but I don't see it. The system chunk assertion
is in some functions but not everywhere, was added when zoned code was
extended so this makes some sense. We also don't validate most of the
btrfs_find_space_info() calls and I don't think we should, besides the
initial setup that must lead to a real error.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ