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] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1612102104050.1986@hadrien>
Date:   Sat, 10 Dec 2016 21:06:44 +0100 (CET)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     Dan Carpenter <dan.carpenter@...cle.com>
cc:     Joe Perches <joe@...ches.com>,
        James Smart <james.smart@...adcom.com>,
        Keith Busch <keith.busch@...el.com>, Jens Axboe <axboe@...com>,
        linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [patch] nvme-fabrics: correct some printk information



On Sat, 10 Dec 2016, Dan Carpenter wrote:

> On Sat, Dec 10, 2016 at 03:27:50AM -0800, Joe Perches wrote:
> > On Sat, 2016-12-10 at 12:06 +0300, Dan Carpenter wrote:
> > > We really don't care where "ctrl" is on the stack since we're just
> > > returning soon what we want is the actual ctrl pointer itself.
> > >
> > > Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
> > >
> > > diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
> > []
> > > @@ -2402,7 +2402,7 @@ enum blk_eh_timer_return
> > >
> > >  	dev_info(ctrl->ctrl.device,
> > >  		"NVME-FC{%d}: new ctrl: NQN \"%s\" (%p)\n",
> > > -		ctrl->cnum, ctrl->ctrl.opts->subsysnqn, &ctrl);
> > > +		ctrl->cnum, ctrl->ctrl.opts->subsysnqn, ctrl);
> >
> > Found by script or inspection?
> >
> > If by script, it seems unlikely there's only 1 instance
> > where an address of an automatic pointer type is used
> > incorrectly.
>
> Script.  But it's using a pretty specific heuristic where we kmalloc a
> pointer and then pass the address.  It prints few warnings.  Probably
> 40% false positives, but the remaining examples of course are 100% false
> positives.

I tried anything that looks like a print, ie has a format string argument,
and was taking the address of a local variable as another argument.  But
there are lots of weird format designators in the kernel that Coccinelle
doesn't know about for which passing the address of a local variable is
reasonable.  So for the moment, there are, as far as I can see, just a lot
of false positives.  I did add improving the support for format strings to
my TODO list.

julia


>
> regards,
> dan carpenter
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ