From: Dan Carpenter <dan.carpenter@oracle.com>
To: Oliver Neukum <oneukum@suse.com>
Cc: David Kahurani <k.kahurani@gmail.com>,
netdev@vger.kernel.org,
syzbot <syzbot+d3dbdf31fbe9d8f5f311@syzkaller.appspotmail.com>,
davem@davemloft.net, jgg@ziepe.ca, kuba@kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Phillip Potter <phil@philpotter.co.uk>,
syzkaller-bugs@googlegroups.com, arnd@arndb.de,
Pavel Skripkin <paskripkin@gmail.com>
Subject: Re: [PATCH] net: ax88179: add proper error handling of usb read errors
Date: Thu, 14 Apr 2022 11:21:15 +0300 [thread overview]
Message-ID: <20220414082115.GA12805@kadam> (raw)
In-Reply-To: <523330e4-cbd7-62a6-9368-417534ddb0b6@suse.com>
On Thu, Apr 14, 2022 at 09:31:56AM +0200, Oliver Neukum wrote:
>
>
> On 13.04.22 17:32, Dan Carpenter wrote:
> >
> > Bug: buffer partially filled. Information leak.
> >
> > If you return the bytes then the only correct way to write error
> > handling is:
> >
> > if (ret < 0)
> > return ret;
> > if (ret != size)
> > return -EIO;
> >
> You have to make up your mind on whether you ever need to read
> answer of a length not known before you try it. The alternative of
> passing a pointer to an integer for length is worse.
How is it worse? Can you give an example, so I will write a static
checker rule for it?
There used to be more APIs that consistently caused bug after bug where
we mixed positives success values with negative error codes. We
converted some bad offenders to return the positive as a parameter
and I was really happy about that.
Another example I used to see a lot is request_irq() saved to an
unsigned. These days I think GCC warns about that? Maybe the build
bots get to it before I do.
regards,
dan carpenter
next prev parent reply other threads:[~2022-04-14 8:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 15:10 [PATCH] net: ax88179: add proper error handling of usb read errors David Kahurani
2022-04-04 15:31 ` Dan Carpenter
2022-04-13 12:36 ` David Kahurani
2022-04-13 15:32 ` Dan Carpenter
2022-04-14 7:31 ` Oliver Neukum
2022-04-14 8:21 ` Dan Carpenter [this message]
2022-04-14 9:13 ` Oliver Neukum
2022-04-04 16:50 ` Pavel Skripkin
2022-04-11 15:11 ` Andy Shevchenko
2022-04-05 9:44 ` Paolo Abeni
2022-04-05 20:44 ` kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2022-04-16 7:48 David Kahurani
2022-04-16 11:05 ` Pavel Skripkin
2022-04-16 11:10 ` Pavel Skripkin
2022-04-16 11:49 ` David Kahurani
2022-04-16 11:53 ` Pavel Skripkin
2022-04-16 11:57 ` Pavel Skripkin
2022-04-19 13:41 ` Paolo Abeni
2022-05-14 13:32 David Kahurani
2022-05-14 16:51 ` Pavel Skripkin
2022-05-14 18:54 ` Dan Carpenter
2022-05-14 18:57 ` Pavel Skripkin
2022-05-16 19:31 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220414082115.GA12805@kadam \
--to=dan.carpenter@oracle.com \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=jgg@ziepe.ca \
--cc=k.kahurani@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=paskripkin@gmail.com \
--cc=phil@philpotter.co.uk \
--cc=syzbot+d3dbdf31fbe9d8f5f311@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).