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:	Wed, 25 Jan 2012 18:10:47 -0500
From:	Josh Boyer <jwboyer@...il.com>
To:	Sven-Haegar Koch <haegar@...net.de>
Cc:	Greg KH <greg@...ah.com>, Paolo Bonzini <pbonzini@...hat.com>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, linux-scsi@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>,
	James Bottomley <JBottomley@...allels.com>
Subject: Re: [v2] Re: [091/129] block: fail SCSI passthrough ioctls on
 partition devices

On Wed, Jan 25, 2012 at 5:51 PM, Sven-Haegar Koch <haegar@...net.de> wrote:
> On Wed, 25 Jan 2012, Greg KH wrote:
>
>> On Tue, Jan 24, 2012 at 05:43:50PM +0100, Paolo Bonzini wrote:
>> > > You need to return -ENOTTY from scsi_verify_blk_ioctl and -ENOIOCTLCMD from
>> > > sd_compat_ioctl, because -ENOIOCTLCMD will not be handled correctly by
>> > > block/ioctl.c.  This would break BLKROSET and BLKFLSBUF done by non-root
>> > > but with the appropriate capabilities.
>> > >
>> > > Fixed patch follows.  If you prefer that I send an interdiff, let me know.
>>
>> Wait, why do you want the stable trees to diverge from what is in
>> Linus's tree with regards to the error codes being returned?
>>
>> That doesn't seem safe, or sane.
>>
>> So for now, I'm going to follow what is in Linus's tree.  If you
>> need/want the error codes to be different, then shouldn't it also be
>> done there as well?
>
> May be because the stable trees do not have
> 07d106d0a33d6063d2061305903deb02489eba20? "vfs: fix up ENOIOCTLCMD error
> handling"?

I believe that is the case, yes.  Linus was unhappy about ENOIOCTLCMD vs.
ENOTTY overall when the patch was first submitted, which lead to that commit.
The patches Paolo submitted for stable are the original versions that apply
directly to 3.2 and older.

07d106d0a isn't really stable material as it was put into 3.3 to catch any odd
fallout from the change.

josh
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ