netdev - Re: [PATCH] scsi_netlink: Remove dead and buggy code

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]

Date:	Tue, 11 Sep 2012 15:40:08 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	James.Smart@...lex.Com, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] scsi_netlink: Remove dead and buggy code

James Bottomley <James.Bottomley@...senPartnership.com> writes:

> On Mon, 2012-09-10 at 15:07 -0400, David Miller wrote:
>> From: ebiederm@...ssion.com (Eric W. Biederman)
>> Date: Fri, 07 Sep 2012 15:39:21 -0700
>> 
>> > 
>> > The scsi netlink code confuses the netlink port id with a process id,
>> > going so far as to read NETLINK_CREDS(skb)->pid instead of the correct
>> > NETLINK_CB(skb).pid.  Fortunately it does not matter because nothing
>> > registers to respond to scsi netlink requests.
>> > 
>> > The only interesting use of the scsi_netlink interface is
>> > fc_host_post_vendor_event which sends a netlink multicast message.
>> > 
>> > Since nothing registers to handle scsi netlink messages kill all of the
>> > registration logic, while retaining the same error handling behavior
>> > preserving the userspace visible behavior and removing all of the
>> > confused code that thought a netlink port id was a process id.
>> > 
>> > This was tested with a kernel allyesconfig build which had no problems.
>> > 
>> > Cc: James Bottomley <James.Bottomley@...allels.com>
>> > Cc: James Smart <James.Smart@...lex.Com>
>> > Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> 
>> James et al., please review and ACK.
>
> I'll defer to the decision of James Smart and the other FC contributors,
> since the FC transport class is really the only one using a netlink
> interface.

So just for curiosity I searched the entire git history for scsi_nl_add_
and the only commit that I found was the addition of that code to the
tree in August of 2008.

Does anyone have any reason to keep scsi_nl_add_transport or
scsi_nl_add_driver that have never been used in the 4 years since
they have been added?

Eric

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