CVE-2024-50276

What it actually does

Double free of the original TX skb when skb expansion occurs outside mse102x_tx_frame_spi(), causing use-after-free crash in skb_release_data called from mse102x_tx_work.

Why it matters to the business

Kernel oops and potential system instability or denial of service on devices using the mse102x SPI Ethernet driver; low ecosystem prevalence limits widespread operational impact.

How an attack unfolds

An attacker with local access or the ability to trigger TX path in the mse102x driver sends traffic requiring skb expansion, causing the driver to free a temporary skb while leaving the original pointer intact; the subsequent free in the tx_work kworker leads to crash. No named threat actors are tied to this specific flaw despite general Linux kernel exploitation campaigns.

How to fix it

Update the Linux kernel to a version containing the fix for the mse102x double-free; apply vendor-supplied packages that resolve the skb lifetime issue in the vertexcom driver.

How to confirm the fix worked

Confirm the driver source no longer frees the original skb on expansion path and that mse102x_tx_work references remain valid; test TX workloads that previously triggered expansion.

Typical attack path

1. Trigger network TX activity on mse102x interface
2. Force skb room expansion inside the driver
3. Allow original skb pointer to be freed again from mse102x_tx_work kworker
4. Observe kernel oops in skb_release_data

How to detect it

Search kernel logs for Oops in skb_release_data followed by mse102x_tx_work kworker; inspect for repeated crashes on systems with the mse102x module loaded.

• skb_release_data+0xb8/0x1d8
• mse102x_tx_work+0x164/0x35c [mse102x]
• Internal error: Oops: 0000000096000004

What your security team should do

• Prioritize kernel updates on systems exposing the mse102x driver
• Monitor for kernel crashes matching the skb_release_data call trace from mse102x_tx_work
• Disable or replace affected hardware if updates cannot be applied promptly