linux-kernel - Re: [PATCH] block: fix FS_IOC_GETLBMD_CAP parsing in blkdev_common

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]

Message-Id: <50e77c3f-4704-4fb8-a3ac-9686d76fad30@app.fastmail.com>
Date: Thu, 10 Jul 2025 13:52:57 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christoph Hellwig" <hch@...radead.org>
Cc: "Christian Brauner" <brauner@...nel.org>,
 "Arnd Bergmann" <arnd@...nel.org>, linux-fsdevel@...r.kernel.org,
 linux-block@...r.kernel.org, "Anuj Gupta" <anuj20.g@...sung.com>,
 "Martin K. Petersen" <martin.petersen@...cle.com>,
 "Kanchan Joshi" <joshi.k@...sung.com>, "LTP List" <ltp@...ts.linux.it>,
 "Dan Carpenter" <dan.carpenter@...aro.org>,
 "Benjamin Copeland" <benjamin.copeland@...aro.org>, rbm@...e.com,
 "Naresh Kamboju" <naresh.kamboju@...aro.org>,
 "Anders Roxell" <anders.roxell@...aro.org>, "Jens Axboe" <axboe@...nel.dk>,
 "Pavel Begunkov" <asml.silence@...il.com>,
 "Alexey Dobriyan" <adobriyan@...il.com>,
 "Darrick J. Wong" <djwong@...nel.org>, "Eric Biggers" <ebiggers@...gle.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: fix FS_IOC_GETLBMD_CAP parsing in blkdev_common_ioctl()

On Thu, Jul 10, 2025, at 12:59, Christoph Hellwig wrote:
>> I think the variant from commit 1b6d968de22b ("xfs: bump
>> XFS_IOC_FSGEOMETRY to v5 structures") where the old structure
>> gets renamed and the existing macro refers to a different
>> command code is more problematic. We used to always require
>> userspace to be built against the oldest kernel headers it could run
>> on. This worked fine in the past but it appears that userspace
>> (in particular glibc) has increasingly expected to also work
>> on older kernels when building against new headers.
>
> This is what I meant.  Note that the userspace in this case also keeps a
> case trying the old structure, but that does indeed require keeping the
> userspace somewhat in lockstep if you do the renaming as in this example.

Right, it's fine for applications that keep a copy of the uapi
header file, because they can implement both versions when they
update to the new version of that file.

Redefining the ioctl command code does break if you have an
unmodified application source tree that unintentionally uses
the updated /usr/include/linux/*.h file. In this case there is
no benefit from the new header because it isn't aware of the
new struct member but it still ends up failing on old kernels.

   Arnd