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: <2c7bfe48-b2f5-41a2-81b9-34a49c139d87@yandex-team.ru>
Date:   Mon, 9 Oct 2023 02:51:13 +0500
From:   Valentin Sinitsyn <valesini@...dex-team.ru>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Tejun Heo <tj@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Dan Williams <dan.j.williams@...el.com>,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH v9 2/2] PCI: Implement custom llseek for sysfs resource
 entries

On 05.10.2023 16:41, Greg Kroah-Hartman wrote:
> On Mon, Sep 25, 2023 at 11:40:13AM +0300, Valentine Sinitsyn wrote:
>> Since commit 636b21b50152 ("PCI: Revoke mappings like devmem"), mmappable
>> sysfs entries have started to receive their f_mapping from the iomem
>> pseudo filesystem, so that CONFIG_IO_STRICT_DEVMEM is honored in sysfs
>> (and procfs) as well as in /dev/[k]mem.
>>
>> This resulted in a userspace-visible regression:
>>
>> 1. Open a sysfs PCI resource file (eg. /sys/bus/pci/devices/*/resource0)
>> 2. Use lseek(fd, 0, SEEK_END) to determine its size
>>
>> Expected result: a PCI region size is returned.
>> Actual result: 0 is returned.
>>
>> The reason is that PCI resource files residing in sysfs use
>> generic_file_llseek(), which relies on f_mapping->host inode to get the
>> file size. As f_mapping is now redefined, f_mapping->host points to an
>> anonymous zero-sized iomem_inode which has nothing to do with sysfs file
>> in question.
>>
>> Implement a custom llseek method for sysfs PCI resources, which is
>> almost the same as proc_bus_pci_lseek() used for procfs entries.
>>
>> This makes sysfs and procfs entries consistent with regards to seeking,
>> but also introduces userspace-visible changes to seeking PCI resources
>> in sysfs:
>>
>> - SEEK_DATA and SEEK_HOLE are no longer supported;
>> - Seeking past the end of the file is prohibited while previously
>>    offsets up to MAX_NON_LFS were accepted (reading from these offsets
>>    was always invalid).
>>
>> Fixes: 636b21b50152 ("PCI: Revoke mappings like devmem")
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Valentine Sinitsyn <valesini@...dex-team.ru>
>> Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>
>> ---
>>   drivers/pci/pci-sysfs.c | 26 +++++++++++++++++++++++++-
>>   1 file changed, 25 insertions(+), 1 deletion(-)
> 
> I'll take these now, for 6.7-rc1, but not mark them as fixes or cc:
Thanks, appreciated.

> stable as this is a new functionality, the code has never worked for
> lseek on these files so it's not like anything was broken :)
In fact, lseek() on PCI resource files in sysfs was broken since commit 
636b21b50152. That was the reason why I started to investigate the 
issue: one of our applications stopped working after a kernel update.

I'm not hundred percent sure if it belongs to stable, but it does fix a 
user-visible regression.

Best,
Valentin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ