linux-kernel - Re: Resend: Another 4.4 to 4.5 floppy issue

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.LNX.2.00.1608021140180.22028@cbobk.fhfr.pm>
Date:	Tue, 2 Aug 2016 11:44:59 +0200 (CEST)
From:	Jiri Kosina <jikos@...nel.org>
To:	Mark Hounschell <markh@...pro.net>
cc:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Resend: Another 4.4 to 4.5 floppy issue

On Wed, 13 Jul 2016, Mark Hounschell wrote:

> > Alright, so you are basically supplementing O_NDELAY flag in order to 
> > avoid check_disk_change() being called. It's rather a coincidence that 
> > it has worked this way, but I agree with you that we can't ignore the 
> > fact that there is userspace relying on this behavior.
> 
> I'm not supplementing anything. The driver _did_ this on its own. 

I mean, you're passing O_NDELAY to open(/dev/fd0) exactly to avoid kernel 
issuing check_disk_change(). That's the only semantics O_NDELAY has for 
fd.

> I just expect to be able to open the drive to get a handle without the 
> kernel attempting to access the media. My apps manage a disk_change on 
> their own. I don't think its check_disk_change that gives me my pain. 
> There is some probe happening that fails when a floppy is installed that 
> is not a "standard" format. That causes the open to fail which is the 
> most pain. Still I should be able to get a handle without any media or 
> even unrecognized media installed.

Yeah, that's check_disk_change().

> > > The original behavior of the floppy driver was correct. I have no 
> > > idea what BUG these changes were supposed to fix but the "fix" 
> > > obviously broke user land. Was this bug reported by some new ROBOT 
> > > test or something? The kernel floppy driver has been stable for 
> > > years now
> > 
> > That's not really true; the code is a racy mess, and this is being 
> > uncovered only when virtualized floppy devices started to exist 
> > (because they are much faster than a real hardware, and the different 
> > timing reveals bugs that were not visible before).
> 
> Forgive me here as I'm ignorant about why any virtualized floppy would 
> require the real physical kernel floppy driver to be involved at all. 

Because VMs (such as qemu) actually do emulate a FDC on a hardware level, 
but don't emulate the timings of the real hardware (which are not mandated 
by the spec, but "are just there").

> > This particular fix was because syzkaller found a way how easily corrupt
> > kernel memory using O_NDELAY to floppy driver; see
> > 
> > 	https://lkml.org/lkml/2016/2/2/848
> > 
> > > so I am really confused as to why these changes were induced.
> > 
> > The floppy driver is in an orphan mode; no new "features" are added "just
> > because". Everything that's happening there is to fix real bugs in the
> > kernel.
> > 
> > I'll look into ways how to fix this, but I am afraid this is going to be
> > really tricky. Therefore we'd have to very likely proceed asap with revert
> > of 09954bad448 and coming up with a workaround that'd still avoid the bug
> > reported by syzkaller.
> 
> I would be happy to do some testing for you if needed. At least with regard to
> our apps.

Could you please check whether my last patch that Jens queued in 
linux-block.git ("floppy: fix open(O_ACCMODE) for ioctl-only open" in 
for-linus branch) remedies at least some of the issues you are seeing? 

Thanks,

-- 
Jiri Kosina
SUSE Labs