From: Dan Carpenter <dan.carpenter@oracle.com>
To: Jaehee Park <jhpark1013@gmail.com>
Cc: Pavel Skripkin <paskripkin@gmail.com>,
Larry.Finger@lwfinger.net, phil@philpotter.co.uk,
gregkh@linuxfoundation.org, linux-staging@lists.linux.dev,
linux-kernel@vger.kernel.org, outreachy@lists.linux.dev
Subject: Re: [PATCH v3 1/7] staging: r8188eu: remove unused member free_bss_buf
Date: Wed, 20 Apr 2022 20:39:26 +0300 [thread overview]
Message-ID: <20220420173926.GE2969@kadam> (raw)
In-Reply-To: <20220420144834.GA1313590@jaehee-ThinkPad-X1-Extreme>
On Wed, Apr 20, 2022 at 10:48:34AM -0400, Jaehee Park wrote:
> On Wed, Apr 20, 2022 at 02:55:34PM +0300, Dan Carpenter wrote:
> > As a kernel community, I don't think we are pro-active enough about
> > preventing bugs. One of my co-workers and I have started a bi weekly
> > phone call to look at CVEs from the previous week and discuss how they
> > could have been prevented or detected earlier. Of course, my solutions
> > are always centered around static analysis because that's my deal but
> > some bugs are caused by process issues, or could be detected with better
> > testing.
> >
> > In this case there were two bugs proposed bugs.
> >
> > 1) The memory leak that Fabio noticed. Smatch is bad at detecting
> > memory leaks. It's a hard problem, because in this case it's
> > across function boundaries.
> >
> > Fabio caught the leak. I don't know if I would have.
> >
> > 2) The NULL dereference.
> >
> > The "&pnetwork->list" expression is not a dereference so this is also
> > a cross function thing. I thought I used to have an unpublished check
> > for bogus addresses like that where pnetwork is NULL.
> >
> > Another is idea is that when you have pnetwork++ and it's a NULL
> > pointer then print an error message. Or even potentially NULL.
> > There are various heuristics to use which mean that "A reasonable
> > person would think this could be NULL".
> >
> > Or another idea would be that we could test patches. Right now we
> > don't really have a way to test these. But, of course, we wish we
> > did.
> >
> > It's not super likely that we would have committed the NULL deref
> > patch. I would have caught that one if you didn't and Fabio likely
> > would have as well. But I like to remove the human error whenever I
> > can.
> >
> > regards,
> > dan carpenter
>
> I'm sorry about the NULL dereference. I wasn't sure about pnetwork
> and I should've asked. I wanted to ask why pbuf should be removed
> when it was being used for pnetwork but ended up not asking and
> sent a faulty patch. Sorry again and thank you for explaining the
> errors. I will be more careful about memory leaks and dereferencing
> errors. Are there checks that I can run to detect these?
I was going to suggest that you could write a check yourself, but then
when I looked at it it became quite complicated. :P
How about I write the check and send you the output tomorrow?
regards,
dan carpenter
next prev parent reply other threads:[~2022-04-20 17:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 18:19 [PATCH v3 0/7] staging: r8188eu: fix warnings reported by checkpatch Jaehee Park
2022-04-19 18:19 ` [PATCH v3 1/7] staging: r8188eu: remove unused member free_bss_buf Jaehee Park
2022-04-19 19:27 ` Pavel Skripkin
2022-04-20 11:55 ` Dan Carpenter
2022-04-20 14:48 ` Jaehee Park
2022-04-20 17:39 ` Dan Carpenter [this message]
2022-04-22 16:13 ` Dan Carpenter
2022-04-20 16:33 ` Greg KH
2022-04-19 18:19 ` [PATCH v3 2/7] staging: r8188eu: remove spaces before tabs Jaehee Park
2022-04-19 18:19 ` [PATCH v3 3/7] staging: r8188eu: remove 'added by' author comments Jaehee Park
2022-04-19 18:19 ` [PATCH v3 4/7] staging: r8188eu: place constants on the right side of tests Jaehee Park
2022-04-19 18:19 ` [PATCH v3 5/7] staging: r8188eu: replace spaces with tabs Jaehee Park
2022-04-19 18:19 ` [PATCH v3 6/7] staging: r8188eu: correct typo in comments Jaehee Park
2022-04-19 18:19 ` [PATCH v3 7/7] staging: r8188eu: remove unused else condition Jaehee Park
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=20220420173926.GE2969@kadam \
--to=dan.carpenter@oracle.com \
--cc=Larry.Finger@lwfinger.net \
--cc=gregkh@linuxfoundation.org \
--cc=jhpark1013@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=outreachy@lists.linux.dev \
--cc=paskripkin@gmail.com \
--cc=phil@philpotter.co.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.