CVE-2024-57889

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

pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking

If a device uses MCP23xxx IO expander to receive IRQs, the following bug can happen:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, ... preemptcount: 1, expected: 0 ... Call Trace: ... _mightresched+0x104/0x10e _mightsleep+0x3e/0x62 mutexlock+0x20/0x4c regmaplockmutex+0x10/0x18 regmapupdatebitsbase+0x2c/0x66 mcp23s08irqsettype+0x1ae/0x1d6 _irqsettrigger+0x56/0x172 _setupirq+0x1e6/0x646 requestthreadedirq+0xb6/0x160 ...

We observed the problem while experimenting with a touchscreen driver which used MCP23017 IO expander (I2C).

The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from concurrent accesses, which is the default for regmaps without .fastio, .disablelocking, etc.

mcp23s08irqsettype() calls regmapupdatebitsbase(), and the latter locks the mutex.

However, _setupirq() locks desc->lock spinlock before calling these functions. As a result, the system tries to lock the mutex whole holding the spinlock.

It seems, the internal regmap locks are not needed in this driver at all. mcp->lock seems to protect the regmap from concurrent accesses already, except, probably, in mcppinconfget/set.

mcp23s08irqsettype() and mcp23s08irqmask/unmask() are called under chipbuslock(), which calls mcp23s08irqbuslock(). The latter takes mcp->lock and enables regmap caching, so that the potentially slow I2C accesses are deferred until chipbusunlock().

The accesses to the regmap from mcp23s08probeone() do not need additional locking.

In all remaining places where the regmap is accessed, except mcppinconfget/set(), the driver already takes mcp->lock.

This patch adds locking in mcppinconfget/set() and disables internal locking in the regmap config. Among other things, it fixes the sleeping in atomic context described above.