CVE-2023-54118

What it actually does

Race condition during sc16is7xx driver probe allows GPIO controller initialization before device setup completes, resulting in kernel oops on uninitialized memory access in sc16is7xx_gpio_direction_output when gpiod_direction_output is called.

Why it matters to the business

May cause unexpected system crashes and downtime on Linux devices using the affected serial hardware, interrupting operations until systems are updated.

How an attack unfolds

Concurrent probing of dependent GPIO consumers during sc16is7xx initialization triggers direction output calls that access unready driver state, leading to kernel panic; no active threat actor exploitation noted.

How to fix it

Apply kernel patch moving GPIO setup later in probe (commit 17b96b5c19bec791b433890549e44ca523dc82aa); update github.com/cosmos/ibc-go/v7 to 7.9.2 or github.com/cosmos/ibc-go/v8 to 8.6.1 where applicable.

How to confirm the fix worked

Confirm presence of the reorder commit in kernel source or updated package versions; reproduce probe sequence and verify absence of oops in logs.

Typical attack path

1. Probe or load sc16is7xx serial driver
2. Initiate parallel device attachment for GPIO consumers
3. Invoke gpiod_direction_output_raw_commit from LED or similar probe
4. Execute sc16is7xx_gpio_direction_output on uninitialized structures
5. Trigger kernel read fault and oops

How to detect it

Inspect kernel logs and dmesg for oops traces containing sc16is7xx_gpio_direction_output and gpiod_direction_output calls during device probe.

• sc16is7xx_gpio_direction_output+0x68/0x108
• Unable to handle kernel read from unreadable memory at virtual address
• gpiod_direction_output_raw_commit

What your security team should do

• Prioritize kernel updates on affected systems given 308 days since publication
• Review dmesg and kernel logs for prior oops referencing the GPIO function
• Test driver loading in lab environments matching production hardware