linux-kernel - Re: floppy: GPF in floppy_rb0

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: <CACT4Y+boTwHo-sLJc8apwyF6=7FTCsDRQ9nwR1Vf7HpzGGj-BA@mail.gmail.com>
Date:	Thu, 28 Jan 2016 11:32:27 +0100
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Jiri Kosina <jikos@...nel.org>
Cc:	NeilBrown <neilb@...e.com>, Takashi Iwai <tiwai@...e.de>,
	Jens Axboe <axboe@...com>, Hannes Reinecke <hare@...e.de>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	LKML <linux-kernel@...r.kernel.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: floppy: GPF in floppy_rb0_cb

On Wed, Jan 27, 2016 at 9:27 PM, Jiri Kosina <jikos@...nel.org> wrote:
> On Wed, 27 Jan 2016, Dmitry Vyukov wrote:
>
>> > Alright, there is a serious issue with how floppy_revalidate() handles
>> > error from lock_fdc() (in-depth explanation for the curious: it doesn't).
>> >
>> > In case wait_for_event_interruptible() is actually interrupted without
>> > succesfully claiming fdc, we proceed with revalidation, causing all kinds
>> > of havoc (because another parallel request is still in progress).
>> >
>> > The whole story with the 'interruptible' parameter to lock_fdc() is funny
>> > as well, because we always wait interruptibly anyway. So it can be nuked.
>> > Most of the lock_fdc() callsites do properly handle error (and propagate
>> > EINTR), but floppy_revalidate() and floppy_check_events() don't.
>> >
>> > Could you please let syzkaller retest with the patch below? It fixes all
>> > the oopses I am able to trigger here.
>>
>> Done. I will get back to you if I see any other oops.
>
> Please also get to me in case you don't see any other oops after the
> timeframe you have been able to reproduce the original problem, so that we
> could consider the issue resolved and I can make proper patch from this
> and send it upstream.


I have not seen any /dev/fd0 related crashes over night. Previously I
seen tons of them, so I guess this bug is fixed.
Please send this upstream.
Thanks