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:	Thu, 5 Jan 2012 09:30:22 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Paolo Bonzini <pbonzini@...hat.com>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	linux-media@...r.kernel.org
Cc:	Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org,
	security@...nel.org, pmatouse@...hat.com, agk@...hat.com,
	jbottomley@...allels.com, mchristi@...hat.com, msnitzer@...hat.com,
	Christoph Hellwig <hch@....de>
Subject: Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI
 passthrough ioctls on partition devices)

On Thu, Jan 5, 2012 at 9:02 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Added, linux-media and Mauro to the Cc, because I'm about to commit
> something like the attached patch to see if anything breaks. We may
> have to revert it if things get too nasty, but we should have done
> this years and years ago, so let's hope not.

Ok, so "It works for me". I'll delay committing it in case somebody
has some quick obvious fixes or comments (like noticing other cases
like the blk_ioctl.c one), but on the whole I think I'll commit it
later today, just so that it will be as early as possible in the merge
window in case there is ENOTTY/EINVAL confusion.

The good news is that no user space can *ever* care about
ENOTTY/EINVAL in the "generic case", since different drivers have
returned different error returns for years. So user space that doesn't
know exactly what it is dealing with will pretty much by definition
not be affected. Except perhaps in a good way - if it uses "perror()"
or "strerror()" or similar, it will now give a much better error
string of "Inappropriate ioctl for device".

However, some applications don't work with "generic devices", but
instead work with a very specific device or perhaps a very specific
subset.

So the exception would be user space apps that know exactly which
driver they are talking about, and that particular driver used to
always return EINVAL before, and now the ENOIOCTLCMD -> ENOTTY fix
means that it returns the proper ENOTTY - and the application has
never seen it, and never tested against it, and breaks.

I don't *think* this happens outside of the media drivers, but we'll
see. It may be that we will have to make certain drivers return EINVAL
explicitly rather than ENOIOCTLCMD and add a comment about why. Sad,
if so, so we'll have little choice. Let's see what the breakage (if
any - cross your fingers) looks like.

                               Linus
--
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