On Tue, Nov 07, 2017 at 09:03:48AM -0800, Linus Torvalds wrote: >On Tue, Nov 7, 2017 at 2:25 AM, Fengguang Wu <[email protected]> wrote: >> >> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. > >Yeah, no it is not new. > >It also likely doesn't matter (I suspect it happens if you try to >force-load crazy modules that don't exist, and ISA doesn't have proper >probing). > >But the code disassembles to > > 0: 8b 50 7c mov 0x7c(%eax),%edx > 3: 83 05 38 86 21 44 01 addl $0x1,X > a:* 8b 4a 0c mov 0xc(%edx),%ecx <-- trapping instruction > d: 83 15 3c 86 21 44 00 adcl $0x0,X+4 > 14: 85 c9 test %ecx,%ecx > >and while I have no idea what that odd addl/adcl is (other than the >obvious "it's a 64-bit increment" - probably some random statistics >due to your config), it looks like the oops is due to > > struct isa_driver *isa_driver = dev->platform_data; > > if (isa_driver->shutdown) > >with isa_driver being NULL (EDX: 00000000). > >So dev->platform_data is NULL, but why that actually happens I don't >know. Some bad ISA device registration that _should_ have failed but >instead got into some half-alive state, I'm sure. > >I'm not sure if anybody cares, but maybe adding a NULL check just to >make the 0day robot not report this is a good idea. > > Linus
I suspect platform_data is being set to NULL when a device match fails (via the snd_es1688_match callback) in the isa_bus_match function. The NULL pointer dereference then subsequently occurs in isa_bus_shutdown since the platform_data member has been reset to indicate an unsupported device. The most straight-forward solution is as mentioned: perform a NULL check to ensure we're actually working with a valid ISA device before blindly poking it. I'll submit a simple patch then that should placate this error. William Breathitt Gray
