On Mon, Dec 12, 2016 at 11:04 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 12 Dec 2016, Alan Stern wrote: > >> On Mon, 12 Dec 2016, Dmitry Vyukov wrote: >> >> > On Mon, Dec 12, 2016 at 10:05 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > > On Mon, 12 Dec 2016, Andrey Konovalov wrote: >> > > >> > >> Hi! >> > >> >> > >> While running the syzkaller fuzzer I've got the following error report. >> > >> >> > >> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dev 2). >> > >> >> > >> WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0 >> > >> gadgetfs: disconnected >> > >> sysfs: cannot create duplicate filename >> > >> '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05' >> > >> Kernel panic - not syncing: panic_on_warn set ... >> > > >> > > I suppose we could check for USB devices that claim to have two >> > > endpoints with the same address. But is it really worthwhile? A >> > > kernel warning isn't so bad when you're dealing with buggy device >> > > firmware. >> > >> > We need a clear distinction between what is a bug in kernel source >> > code and what is incorrect user-space code. Otherwise no automated >> > testing is possible. WARNING means bug in kernel source code. >> >> I don't necessarily agree with that. Is it documented anywhere? >> >> > If it is >> > not a bug in kernel source code, then it must not produce a WARNING. > > What about a memory allocation failure? The memory management part of > the kernel produces a WARNING message if an allocation fails and the > caller did not specify __GFP_NOWARN. > > There is no way for a driver to guarantee that a memory allocation > request will succeed -- failure is always an option. But obviously > memory allocation failures are not bugs in the kernel. > > Are you saying that mm/page_alloc.c:warn_alloc() should produce > something other than a WARNING? The main thing I am saying is that we absolutely need a way for a human or a computer program to be able to determine if there is anything wrong with kernel or not. Page_alloc produces a WARNING iff you ask for an amount of memory that can't possibly be allocated under any circumstances (order >= MAX_ORDER). That's not just an allocation failure. Kernel itself should not generally ask for such large amounts of memory. If the allocation size is dictated by user, then kernel code should either use __GFP_NOWARN, or impose own stricter limit dictated by context (e.g. if it's a text command of known format, then limit can be as small as say 128 bytes). Re fake hardware. panic_on_warn will definitely cause problems. I don't know if it used in any paranoid production systems or not, though. But more generally, I don't see how it is different from incorrect syscall arguments or nonsensical network packets received from free internet. In ideal productions environments none of these incorrect inputs to kernel should happen. I don't see any single reason to not protect kernel from incorrect input in this case as well, as we do in all other cases. In particular, it would resolve a very real and practical issue for us -- fuzzer will not reboot machine every minute, and we will not spend time looking at these WARNINGs, and we will not spend your time by reporting these WARNINGs. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
