Executive Summary



This vulnerability is currently undergoing analysis and not all information is available. Please check back soon to view the completed vulnerability summary
Informations
Name CVE-2024-57889 First vendor Publication 2025-01-15
Vendor Cve Last vendor Modification 2025-01-15

Security-Database Scoring CVSS v3

Cvss vector : N/A
Overall CVSS Score NA
Base Score NA Environmental Score NA
impact SubScore NA Temporal Score NA
Exploitabality Sub Score NA
 
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores

Detail

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
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...
preempt_count: 1, expected: 0
...
Call Trace:
...
__might_resched+0x104/0x10e
__might_sleep+0x3e/0x62
mutex_lock+0x20/0x4c
regmap_lock_mutex+0x10/0x18
regmap_update_bits_base+0x2c/0x66
mcp23s08_irq_set_type+0x1ae/0x1d6
__irq_set_trigger+0x56/0x172
__setup_irq+0x1e6/0x646
request_threaded_irq+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 .fast_io, .disable_locking, etc.

mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter locks the mutex.

However, __setup_irq() 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 mcp_pinconf_get/set.

mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes mcp->lock and enables regmap caching, so that the potentially slow I2C accesses are deferred until chip_bus_unlock().

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

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

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

Original Source

Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-57889

Sources (Detail)

https://git.kernel.org/stable/c/0310cbad163a908d09d99c26827859365cd71fcb
https://git.kernel.org/stable/c/788d9e9a41b81893d6bb8faa05f045c975278318
https://git.kernel.org/stable/c/830f838589522404cd7c2f0f540602f25034af61
https://git.kernel.org/stable/c/8c6fd5803b988a5e78c9b9e42c70a936d7cfc6ec
https://git.kernel.org/stable/c/9372e160d8211a7e17f2abff8370794f182df785
https://git.kernel.org/stable/c/a37eecb705f33726f1fb7cd2a67e514a15dfe693
https://git.kernel.org/stable/c/c55d186376a87b468c9ee30f2195e0f3857f61a0
Source Url

Alert History

If you want to see full details history, please login or register.
0
Date Informations
2025-01-15 17:20:30
  • First insertion