linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@lip6.fr>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>,
	Konstantin Khlebnikov <k.khlebnikov@samsung.com>,
	kexec@lists.infradead.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Michal Marek <mmarek@suse.cz>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Gilles Muller <Gilles.Muller@lip6.fr>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	linux-crypto@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 1/2 v2] scripts/coccinelle: catch freeing cryptographic structures via kfree
Date: Sun, 23 Nov 2014 17:45:18 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.02.1411231743320.2037@localhost6.localdomain6> (raw)
In-Reply-To: <CALYGNiOiErex4-WfqfCKHuZAMoA6SPvQVHjAx0imeeB6bzcbNQ@mail.gmail.com>



On Wed, 19 Nov 2014, Konstantin Khlebnikov wrote:

> On Wed, Nov 19, 2014 at 12:41 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> >> +// Comments: There are false positives in crypto/ where they are
> >> actually freed.
> >
> > I didn't really understand this comment.  I ran the semantic patch and got
> > around 10 results, but it wasn't clear to me how to see which were false
> > positives.
> 
> I mean false positives in code inside directory crypto/ where this
> subsystem lives.
> 
> ./arch/x86/crypto/fpu.c:143:1-6: WARNING: invalid free of
> crypto_alloc_* allocated data
> ./crypto/algapi.c:846:1-6: WARNING: invalid free of crypto_alloc_*
> allocated data
> ./crypto/lrw.c:378:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/ecb.c:163:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/ctr.c:242:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/ctr.c:419:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/ctr.c:428:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/pcbc.c:273:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/cts.c:329:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/cbc.c:267:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> ./crypto/xts.c:340:1-6: WARNING: invalid free of crypto_alloc_* allocated data
> 
> This is kfree calls on error paths in constructors or in destructors
> which actually frees memory when crypto_free_* is called.

Sorry, but I am not sure to fully understand the issue.  Is it actually 
just the case that crypto_alloc_instance and crypto_alloc_instance2 should 
not be in the list of allocation functions, because their results should 
be freed with kfree?

julia


> 
> >
> > I would suggest to extend the rule a little bit to include information
> > about where the allocation call is:
> 
> Not sure if this is necessary. This part of crypto-api is simple.
> 
> >
> > ///
> > /// Structures allocated by crypto_alloc_* must be freed using crypto_free_*.
> > /// This finds freeing them by kfree.
> > ///
> > // Confidence: Moderate
> > // Copyright: (C) 2014 Konstantin Khlebnikov,  GPLv2.
> > // Comments: There are false positives in crypto/ where they are actually freed.
> > // Keywords: crypto, kfree
> > // Options: --no-includes --include-headers
> >
> > virtual org
> > virtual report
> > virtual context
> >
> > @r depends on context || org || report@
> > expression x;
> > position p1;
> > @@
> >
> > (
> >  x = crypto_alloc_base@p1(...)
> > |
> >  x = crypto_alloc_cipher@p1(...)
> > |
> >  x = crypto_alloc_ablkcipher@p1(...)
> > |
> >  x = crypto_alloc_aead@p1(...)
> > |
> >  x = crypto_alloc_instance@p1(...)
> > |
> >  x = crypto_alloc_instance2@p1(...)
> > |
> >  x = crypto_alloc_comp@p1(...)
> > |
> >  x = crypto_alloc_pcomp@p1(...)
> > |
> >  x = crypto_alloc_hash@p1(...)
> > |
> >  x = crypto_alloc_ahash@p1(...)
> > |
> >  x = crypto_alloc_shash@p1(...)
> > |
> >  x = crypto_alloc_rng@p1(...)
> > )
> >
> > @pb@
> > expression r.x;
> > position p;
> > @@
> >
> > * kfree@p(x)
> >
> > @script:python depends on org@
> > p << pb.p;
> > p1 << r.p1;
> > @@
> >
> > msg="WARNING: invalid free of crypto_alloc_* allocated data"
> > coccilib.org.print_todo(p[0], msg)
> > coccilib.org.print_link(p1[0], "allocation")
> >
> > @script:python depends on report@
> > p << pb.p;
> > p1 << r.p1;
> > @@
> >
> > msg="WARNING: invalid free of crypto_alloc_* allocated data, allocated on line %s" % (p1[0].line)
> > coccilib.report.print_report(p[0], msg)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 

      reply	other threads:[~2014-11-23 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17 14:14 [PATCH 1/2] scripts/coccinelle: catch freeing cryptographic structures via kfree Konstantin Khlebnikov
2014-11-17 14:14 ` [PATCH 2/2] kernel/kexec: free crypto_shash using crypto_free_shash Konstantin Khlebnikov
2014-11-17 15:30 ` [PATCH 1/2] scripts/coccinelle: catch freeing cryptographic structures via kfree Julia Lawall
2014-11-17 15:40   ` Konstantin Khlebnikov
2014-11-18 10:50 ` [PATCH 1/2 v2] " Konstantin Khlebnikov
2014-11-19  9:41   ` Julia Lawall
2014-11-19 15:06     ` Konstantin Khlebnikov
2014-11-23 16:45       ` Julia Lawall [this message]

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=alpine.DEB.2.02.1411231743320.2037@localhost6.localdomain6 \
    --to=julia.lawall@lip6.fr \
    --cc=Gilles.Muller@lip6.fr \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=k.khlebnikov@samsung.com \
    --cc=kexec@lists.infradead.org \
    --cc=koct9i@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=nicolas.palix@imag.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).