linux-ext4 - Re: [syzbot] WARNING in iomap

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]

Date:   Sat, 20 Aug 2022 23:29:05 -0700
From:   hch <hch@...radead.org>
To:     Siddh Raman Pant <code@...dh.me>
Cc:     Matthew Wilcox <willy@...radead.org>, david <david@...morbit.com>,
        djwong <djwong@...nel.org>, fgheet255t <fgheet255t@...il.com>,
        hch <hch@...radead.org>, linux-ext4 <linux-ext4@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        riteshh <riteshh@...ux.ibm.com>,
        syzbot+a8e049cd3abd342936b6 
        <syzbot+a8e049cd3abd342936b6@...kaller.appspotmail.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: [syzbot] WARNING in iomap_iter

On Thu, Aug 18, 2022 at 08:51:16PM +0530, Siddh Raman Pant wrote:
> On Thu, 18 Aug 2022 20:20:02 +0530  Matthew Wilcox  wrote:
> > I don't think changing these from u64 to s64 is the right way to go.
> 
> Why do you think so? Is there somnething I overlooked?
> 
> I think it won't intorduce regression, since if something is working,
> it will continue to work. If something does break, then they were
> relying on overflows, which is anyways an incorrect way to go about.

Well, for example userspace code expecting unsignedness of these
types could break.  So if we really think changing the types is so
much preferred we'd need to audit common userspace first.  Because
of that I think the version proposed by willy is generally preferred.

> Also, it seems even the 32-bit compatibility structure uses signed
> types.

We should probably fix that as well.