CVE-2022-49193

In the Linux kernel, the following vulnerability has been resolved:

ice: fix 'scheduling while atomic' on aux critical err interrupt

There's a kernel BUG splat on processing aux critical error interrupts in icemiscintr():

[ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Call Trace: [ 2101.063229] <IRQ> [ 2101.065252] dumpstack+0x41/0x60 [ 2101.068587] _schedulebug.cold.100+0x4c/0x58 [ 2101.073060] _schedule+0x6a4/0x830 [ 2101.076570] schedule+0x35/0xa0 [ 2101.079727] schedulepreemptdisabled+0xa/0x10 [ 2101.084284] _mutexlock.isra.7+0x310/0x420 [ 2101.088580] ? icemiscintr+0x201/0x2e0 [ice] [ 2101.093078] icesendeventtoaux+0x25/0x70 [ice] [ 2101.097921] icemiscintr+0x220/0x2e0 [ice] [ 2101.102232] _handleirqeventpercpu+0x40/0x180 [ 2101.106965] handleirqeventpercpu+0x30/0x80 [ 2101.111434] handleirqevent+0x36/0x53 [ 2101.115292] handleedgeirq+0x82/0x190 [ 2101.119148] handleirq+0x1c/0x30 [ 2101.122480] doIRQ+0x49/0xd0 [ 2101.125465] commoninterrupt+0xf/0xf [ 2101.129146] </IRQ> ...

As Andrew correctly mentioned previously[0], the following call ladder happens:

icemiscintr() <- hardirq icesendeventtoaux() devicelock() mutexlock() mightsleep() mightresched() <- oops

Add a new PF state bit which indicates that an aux critical error occurred and serve it in iceservicetask() in process context. The new icepf::oicrerr_reg is read-write in both hardirq and process contexts, but only 3 bits of non-critical data probably aren't worth explicit synchronizing (and they're even in the same byte [31:24]).

[0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch