linux-kernel - Re: [PATCH 1/2] staging/sep: Fix smatch false positive about potential NULL dereference in sep

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: <20130219122508.GA9138@mwanda>
Date:	Tue, 19 Feb 2013 15:25:08 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	Peter Huewe <peterhuewe@....de>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	Joe Perches <joe@...ches.com>,
	"Robert P. J. Day" <rpjday@...shcourse.ca>
Subject: Re: [PATCH 1/2] staging/sep: Fix smatch false positive about
 potential NULL dereference in sep_main.c

On Tue, Feb 19, 2013 at 01:07:27PM +0100, Peter Huewe wrote:
> Smatch complains about a potential NULL pointer dereference:
> 
> sep_main.c:2312 sep_construct_dma_tables_from_lli() error: potential
> NULL dereference 'info_out_entry_ptr'.
> 
> info_out_entry_ptr is initialized with NULL and if info_in_entry_ptr is
> not NULL it gets derefenced.
> However info_out_entry_ptr is only NULL in the first iteration of the
> while loop and in this case info_in_entry_ptr is also NULL (as indicated
> by the comment /* If info entry is null - this is the first table built */
> -> this is a false positive.
> 
> Nevertheless we add a check for info_out_entry_ptr to silence this
> warning and make it more robust in regard to code changes.
> 

Smatch doesn't handle loops very well.  Of course, all along I've
wanted to fix this, but it's a bit complicated so it could be
another year or two before it actually happens.

Generally, as a philosophy, I always say never to change the code
for false positives.  It should be Smatch which changes.

Also the other thing is that with Smatch I deliberately allow more
false positives than GCC does.  It's a trade off between being
ambitious in looking for bugs and being annoying to users.

When Smatch looks at this code it sees the else side as impossible
to reach.  Perhaps I should add a hack in that if the code is in an
impossible to reach place then don't print a warning...  It would
be better to just fix loop handling...  I'm not sure.

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/