linux-kernel - Re: CodingStyle: Clarify and complete chapter 7

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]

Date:	Mon, 15 Aug 2016 17:38:42 +0200
From:	SF Markus Elfring <elfring@...rs.sourceforge.net>
To:	Mark D Rustad <mrustad@...il.com>
Cc:	Jonathan Corbet <corbet@....net>, Jean Delvare <jdelvare@...e.de>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: CodingStyle: Clarify and complete chapter 7

>>> A common type of bug to be aware of is "one err bugs" which look like this:
>>>
>>> -    err:
>>> +     err:
>>>          kfree(foo->bar);
>>>          kfree(foo);
>>>          return ret;
>>>
>>>  The bug in this code is that on some exit paths "foo" is NULL.  Normally the
>>
>> ...except that kfree() can handle null pointers just fine, so this isn't
>> actually a bug, right?  Someday when somebody has time it would be good to
>> come up with a better example.
> 
> But if foo is NULL,

An important condition …

> foo->bar is not NULL

I wonder about this information. Which run-time environment will provide
this behaviour?

> and so kfree will have a problem with it.

I find that the parameter evaluation will result in side effects
(because of a null pointer access) which are usually unwanted.
So the execution of this function call will eventually not start.

> So this is a bug.

How do you think about further software development possibilities to improve
corresponding exception handling?

How much can the selection of jump labels influence the software design?

Regards,
Markus