CVE-2025-38452

What it actually does

Null pointer dereference occurs in rtsn_probe() when rcar_gen4_ptp_alloc() returns NULL without a subsequent validity check, leading to a crash during network device initialization.

Why it matters to the business

Systems using the affected Ethernet driver may experience unexpected kernel panics or service disruption during hardware initialization or module loading, increasing downtime risk on affected Linux deployments.

How an attack unfolds

An attacker with local access or the ability to trigger device probe (such as through module insertion or hardware events) can cause the unhandled NULL return from rcar_gen4_ptp_alloc() to dereference, crashing the kernel.

How to fix it

Apply the fix from commit 9f260e16b297f8134c5f90bb5a20e805ff57e853 in the Linux kernel stable repository or upgrade to the corresponding fixed Debian packages (e.g., webkit2gtk 2.48.5-1 or 2.48.5-1~deb12u1 as applicable).

How to confirm the fix worked

Confirm the presence of the check for rcar_gen4_ptp_alloc() return value in rtsn_probe() after applying the update and verify the running kernel contains commit 9f260e16b297f8134c5f90bb5a20e805ff57e853.

Typical attack path

1. Gain local access or ability to load kernel modules
2. Trigger rtsn device probe via hardware insertion or explicit module load
3. rcar_gen4_ptp_alloc() returns NULL
4. rtsn_probe() dereferences the NULL pointer without checking
5. Kernel panic or system crash occurs

How to detect it

Review kernel logs for oops or panic messages mentioning rtsn_probe or rcar_gen4_ptp_alloc around device initialization events; no remote indicators are typically present.

What your security team should do

• Prioritize patching systems that load the rtsn driver
• Monitor for kernel oops or panic logs related to rtsn_probe
• Test the updated kernel in a staging environment before broad deployment
• Restrict local module loading where feasible until patched