linux-kernel - Re: [PATCH 60/60] staging: lustre: libcfs: fix minimum size check for libcfs ioctl

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.LFD.2.20.1701310203320.7738@casper.infradead.org>
Date:   Tue, 31 Jan 2017 02:25:22 +0000 (GMT)
From:   James Simmons <jsimmons@...radead.org>
To:     Dan Carpenter <dan.carpenter@...cle.com>
cc:     Liang Zhen <liang.zhen@...el.com>,
        Amir Shehata <amir.shehata@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devel@...verdev.osuosl.org,
        Andreas Dilger <andreas.dilger@...el.com>,
        Oleg Drokin <oleg.drokin@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lustre Development List <lustre-devel@...ts.lustre.org>,
        Doug Oucharek <doug.s.oucharek@...el.com>
Subject: Re: [PATCH 60/60] staging: lustre: libcfs: fix minimum size check
 for libcfs ioctl


> It looks like what happened is there were two patches applied out of
> sync.  Let's add a fixes tag and CC the original author.

So the only problem here is the commit message. I will update it then.
 
> Fixes: ed2f549dc0f6 ("staging: lustre: libcfs: test if userland data is to small")
> 
> This patch was probably correct when it was written but commit
> 1290932728e5 ("staging: lustre: Dynamic LNet Configuration (DLC) IOCTL
> changes") ended up getting applied first so the size was wrong.
> 
> The lstcon_ioctl_entry() function doesn't have enough size checking.

This sounds like a separate patch. I will open a ticket about this and
your comments below.

> Also I'm uncomfortable with:
> 
> 	data = container_of(hdr, struct libcfs_ioctl_data, ioc_hdr);
> 
> If hdr isn't the first member of the struct then the code is broken but
> container_of() implies that that isn't a hard requirement.  It should
> just be:
> 
> 	data = (struct libcfs_ioctl_data *)hdr;

Don't know if hdr being first is a hard requirment. Doug, Amir do you know 
if it is an requirement?