linux-kernel - Re: [PATCH] scripts: coccinelle: kfree with TRACE

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: <87ha298psy.fsf@nemi.mork.no>
Date:	Tue, 22 Jul 2014 15:51:25 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Nicholas Mc Guire <der.herr@...r.at>
Cc:	Michal Marek <mmarek@...e.cz>, Julia Lawall <Julia.Lawall@...6.fr>,
	Gilles Muller <Gilles.Muller@...6.fr>,
	Nicolas Palix <nicolas.palix@...g.fr>, cocci@...teme.lip6.fr,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scripts: coccinelle: kfree with TRACE_RET before ref is ok (resent)

Nicholas Mc Guire <der.herr@...r.at> writes:

> kfree.cocci currently triggers on constructs like
> (resending with proper CC list and subject line)
>
> drivers/staging/rts5208/spi.c
> 596    if (retval < 0) {
> 597            kfree(buf);
> 598            rtsx_clear_spi_error(chip);
> 599            spi_set_err_code(chip, SPI_HW_ERR);
> 600            TRACE_RET(chip, STATUS_FAIL);
> 601    }
> 602
> 603    rtsx_stor_access_xfer_buf(buf, pagelen, srb, &index, &offset,
>                             TO_XFER_BUF);
>
> with:
>
> ./drivers/staging/rts5208/spi.c:603:28-31: ERROR: reference preceded 
> by free on line 597
>
> but this should be fine - so TRACE_RET is added to the list of calls 
> "protecting" access to freed objects see drivers/staging/rts5208/trace.h

The TRACE_RET macro is a serious coding style violation. Fix that and
the error will go away.  Don't change scripts to hide issues with the
code. The code above won't just trigger an error in kfree.cocci but also
in the head of any sane person.

>From Documentation/CodingStyle:

<quote>
Things to avoid when using macros:

1) macros that affect control flow:

#define FOO(x)                                  \
        do {                                    \
                if (blah(x) < 0)                \
                        return -EBUGGERED;      \
        } while(0)

is a _very_ bad idea.  It looks like a function call but exits the "calling"
function; don't break the internal parsers of those who will read the code.
</quote>


Bjørn
--
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/