In the Linux kernel, the following vulnerability has been resolved:
spi: fix null pointer dereference within spi_sync
If spisync() is called with the non-empty queue and the same spimessage is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spifinalizecurrent_message().
With function inlining disabled, the call stack might look like this:
rawspinlockirqsave from completewithflags+0x18/0x58 completewithflags from spicomplete+0x8/0xc spicomplete from spifinalizecurrentmessage+0xec/0x184 spifinalizecurrentmessage from spitransferonemessage+0x2a8/0x474 spitransferonemessage from _spipumptransfermessage+0x104/0x230 _spipumptransfermessage from _spitransfermessagenoqueue+0x30/0xc4 _spitransfermessagenoqueue from _spisync+0x204/0x248 _spisync from spisync+0x24/0x3c spisync from mcp251xfdregmapcrcread+0x124/0x28c [mcp251xfd] mcp251xfdregmapcrcread [mcp251xfd] from regmaprawread+0xf8/0x154 _regmaprawread from _regmapbusread+0x44/0x70 _regmapbusread from _regmapread+0x60/0xd8 regmapread from regmapread+0x3c/0x5c regmapread from mcp251xfdalloccanerrskb+0x1c/0x54 [mcp251xfd] mcp251xfdalloccanerrskb [mcp251xfd] from mcp251xfdirq+0x194/0xe70 [mcp251xfd] mcp251xfdirq [mcp251xfd] from irqthreadfn+0x1c/0x78 irqthreadfn from irqthread+0x118/0x1f4 irqthread from kthread+0xd8/0xf4 kthread from retfromfork+0x14/0x28
Fix this by also setting message->complete to NULL when the transfer is complete.