linux-kernel - Re: [PATCH] Fix for possible null pointer dereference in node.c

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] [day] [month] [year] [list]

Message-ID: <CAFo99gYAOZesd69GcDMnLAJKrY60Exsxea=z0tgD0sY3=j_Yeg@mail.gmail.com>
Date:	Sun, 18 May 2014 19:14:20 +0200
From:	Rickard Strandqvist <rickard_strandqvist@...ctrumdigital.se>
To:	Dan Carpenter <dan.carpenter@...cle.com>
Cc:	devel@...verdev.osuosl.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Masood Mehmood <ody.guru@...il.com>
Subject: Re: [PATCH] Fix for possible null pointer dereference in node.c

Hi

The approximately 5,000 errors were not only null pointers, but
uninitialized variables, etc. also a mixture of error and warnings.
Same I did not consider a reall error. Then a bunch of warnings for
printf("%d", unsigned int)  and vice versa, which I have not even
bothered to check even.

Regarding the possible use of NULL pointer that I started with, so
reacts cppcheck that there is a check of NULL in some places, but not
others.
As examples:

drivers/staging/tidspbridge/rmgr/node.c : 2365] ->
[drivers/staging/tidspbridge/rmgr/node.c : 2368] :  (warning) Possible
null pointer dereference :  hnode - otherwise it is redundant to check
it against null.

So suppose a lot of it stems from the old code then.


Best regards
Rickard Strandqvist


2014-05-18 18:22 GMT+02:00 Dan Carpenter <dan.carpenter@...cle.com>:
> On Sun, May 18, 2014 at 05:49:52PM +0200, Rickard Strandqvist wrote:
>> Hi
>>
>> When I run cppcheck find the about 5,000 errors, of these, I selected
>> the 100 most serious and has made patches. But my ability to immerse
>> myself in each failure has been limited unfortunately.
>>
>
> I am familiar with that feeling.  ;)
>
> With Smatch, I ignore inconsistent NULL checking like this when we know
> that the parameter is always non-NULL.  It was just too much hassle to
> deal with.
>
> These days I tend to report more bugs instead of fixing them myself.  I
> run on linux-next and complain to the original author as soon as the
> buggy code is merged.  If the code is old, then my experience is that no
> one will fix it.
>
> Also 5000 inconsistent NULL checks seems like too high of a figure.  For
> my inconsistent NULL checks I get 215 of these warnings:
>
>         sound/i2c/other/ak4xxx-adda.c:808 build_adc_controls()
>         error: we previously assumed 'ak->adc_info' could be null (see line 789)
>
> And 75 of these:
>
>         fs/efs/inode.c:298 efs_map_block()
>         warn: variable dereferenced before check 'bh' (see line 292)
>
> regards,
> dan carpenter
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/