CVE-2025-38653

What it actually does

Use-after-free when proc_reg_open checks pde->proc_ops->proc_lseek directly after a prior proc_get_inode fix, allowing rmmod to free structures while proc_lseek is still referenced.

Why it matters to the business

Kernel instability or local privilege escalation risk on Linux systems using the proc filesystem; high downstream impact due to kernel prevalence in servers and containers, though low exploit likelihood reduces immediate operational disruption.

How an attack unfolds

An attacker with local access triggers concurrent proc file operations and module unload to hit the window where the freed proc_ops pointer is dereferenced during lseek handling.

How to fix it

Upgrade to fixed kernel commit c35b0feb80b48720dfbbf4e33759c7be3faaebb6 or later; for Chainguard packages apply openjdk-8-openj9 0.53.0-r1 or newer that incorporates the corrected kernel.

How to confirm the fix worked

Confirm presence of commit c35b0feb80b48720dfbbf4e33759c7be3faaebb6 in the running kernel source; verify no direct pde->proc_ops->proc_lseek access remains in proc_reg_open.

Typical attack path

1. Obtain local unprivileged access on a Linux host
2. Open a proc file descriptor and initiate lseek while a related kernel module is unloaded
3. Trigger the UAF to corrupt kernel memory or redirect execution
4. Escalate to root or cause denial of service

How to detect it

Review kernel logs for oops or UAF warnings involving proc filesystem during module unload; inspect auditd or syscall traces for unusual lseek activity on proc entries around rmmod events.

What your security team should do

• Prioritize kernel updates on container hosts and servers within standard patch cycles given low EPSS and absence from KEV
• Monitor for related privilege-escalation activity in container-optimized OS environments
• Audit custom kernel modules that interact with proc filesystem for similar UAF patterns