linux-kernel - RE: [PATCH v3] qnx4: qnx4_block

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: <7d978bf40c5845e8b89a740250ba958a@AcuMS.aculab.com>
Date:   Tue, 3 Nov 2020 10:54:02 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Tong Zhang' <ztong0001@...il.com>, Anders Larsen <al@...rsen.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3] qnx4: qnx4_block_map error handling

From: Tong Zhang
> Sent: 02 November 2020 23:14
> 
> qnx4_block_map() may return -EIO on funny qnx4 fs image, in this case do
> not interpret -EIO as a correct block number

That commit message is now wrong.

Also 'blknum' is only 'unsigned long' so ~0ull is wrong.
It can be worth injecting an error and checking the error
propagation works.

What is the actual maximum file size?
Is there actually an 'out of range' blknum value
that can be used to signify an error without
changing the return value to 'long long'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)