CVE-2024-56574

What it actually does

Null pointer dereference in ts2020_probe() when platform data is absent during dynamic I2C device registration via sysfs, leading to KASAN-reported access at invalid address.

Why it matters to the business

May cause kernel crashes or denial of service on affected Linux systems when I2C devices are added dynamically through sysfs, potentially disrupting media or tuner hardware operations on older Ubuntu kernels.

How an attack unfolds

An attacker with root privileges writes a device address to /sys/bus/i2c/devices/i2c-*/new_device, causing the ts2020 driver probe to execute without platform data and dereference a null pointer.

How to fix it

Upgrade affected packages to fixed versions: linux (Ubuntu 14.04 LTS) to 3.13.0-91.138 or later, linux-aws (Ubuntu 14.04 LTS) to 4.4.0-1002.2, linux-lts-xenial (Ubuntu 14.04 LTS) to 4.4.0-28.47~14.04.1, linux (Ubuntu 16.04 LTS) to 4.4.0-28.47, linux-aws (Ubuntu 16.04 LTS) to 4.4.0-1001.10, linux-gke (Ubuntu 16.04 LTS) to 4.4.0-1003.3, linux-hwe (Ubuntu 16.04 LTS) to 4.8.0-36.36~16.04.1, linux-raspi2 (Ubuntu 16.04 LTS) to 4.4.0-1016.22, linux-snapdragon (Ubuntu 16.04 LTS) to 4.4.0-1019.22, linux-lts-utopic (Ubuntu 14.04 LTS) to 3.16.0-76.98~14.04.1, linux-lts-vivid (Ubuntu 14.04 LTS) to 3.19.0-64.72~14.04.1, linux-lts-wily (Ubuntu 14.04 LTS) to 4.2.0-41.48~14.04.1.

How to confirm the fix worked

Confirm kernel package versions match or exceed listed fixed releases, attempt safe reproduction of sysfs device registration in a test environment, and verify absence of null dereference via KASAN or crash logs.

Typical attack path

1. Obtain root or sufficient privileges on an affected Linux system
2. Identify an I2C bus and write device address string to new_device sysfs entry
3. Trigger ts2020_probe execution path that assumes platform data presence
4. Access null pointer resulting in kernel panic or oops

How to detect it

Review kernel logs and dmesg for KASAN null-ptr-deref reports or crashes in ts2020_probe during I2C device registration; check systemd-udevd or similar processes triggering the probe.

What your security team should do

• Apply listed kernel package updates immediately on all affected Ubuntu systems
• Restrict unprivileged write access to I2C sysfs entries where possible
• Monitor for kernel oops/panic reports involving ts2020_probe
• Audit systems for dynamic I2C device additions via sysfs