linux-kernel - Re: [PATCH] soc: aspeed: fix a ternary sign expansion bug

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: <YIFBQ50rcZO3NDFD@zeniv-ca.linux.org.uk>
Date:   Thu, 22 Apr 2021 09:26:27 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     Joel Stanley <joel@....id.au>, Andrew Jeffery <andrew@...id.au>,
        "Chia-Wei, Wang" <chiawei_wang@...eedtech.com>,
        Jae Hyun Yoo <jae.hyun.yoo@...el.com>,
        John Wang <wangzhiqiang.bj@...edance.com>,
        Brad Bishop <bradleyb@...ziesquirrel.com>,
        Patrick Venture <venture@...gle.com>,
        Benjamin Fair <benjaminfair@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Robert Lippert <rlippert@...gle.com>,
        linux-aspeed@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] soc: aspeed: fix a ternary sign expansion bug

On Thu, Apr 22, 2021 at 09:24:59AM +0000, Al Viro wrote:
> On Thu, Apr 22, 2021 at 12:11:44PM +0300, Dan Carpenter wrote:
> > The intent here was to return negative error codes but it actually
> > returns positive values.  The problem is that type promotion with
> > ternary operations is quite complicated.
> > 
> > "ret" is an int.  "copied" is a u32.  And the snoop_file_read() function
> > returns long.  What happens is that "ret" is cast to u32 and becomes
> > positive then it's cast to long and it's still positive.
> > 
> > Fix this by removing the ternary so that "ret" is type promoted directly
> > to long.
> 
> Hmm...  Let's grep for kfifo_to_user() - smells like a possible recurring bug...
> Yup -
> 
> samples/kfifo/bytestream-example.c:138: ret = kfifo_to_user(&test, buf, count, &copied);
> samples/kfifo/inttype-example.c:131:    ret = kfifo_to_user(&test, buf, count, &copied);
> samples/kfifo/record-example.c:145:     ret = kfifo_to_user(&test, buf, count, &copied);
> 
> All three are exactly like that one.

Nevermind, you've already caught and posted that bunch.  Sorry for noise...