CVE-2022-48636

What it actually does

Race condition in dasd_alias_get_start_dev allows pavgroup pointer to be NULL without lcu->lock held, resulting in NULL pointer dereference and kernel Oops.

Why it matters to the business

Potential kernel panic and system crash on s390 mainframes using DASD with PAV, causing unplanned downtime and service interruption.

How an attack unfolds

Local attacker triggers concurrent execution of dasd_alias_get_start_dev and _lcu_update to exploit the unprotected window where pavgroup is set to NULL.

How to fix it

Apply the upstream fix that checks pavgroup while holding lcu->lock; upgrade to a kernel containing commit resolving the race.

How to confirm the fix worked

Confirm kernel source contains the lock-protected pavgroup check in dasd_alias_get_start_dev and test concurrent LCU update workloads for stability.

Typical attack path

1. Obtain local shell access on affected s390 system
2. Perform concurrent DASD alias or LCU operations that invoke the vulnerable paths
3. Trigger the race to dereference NULL pavgroup and induce Oops

How to detect it

Search kernel logs and crash dumps for Oops traces mentioning dasd_alias_get_start_dev or pavgroup NULL dereference around LCU update timing.

• dasd_alias_get_start_dev
• pavgroup
• _lcu_update

What your security team should do

• Prioritize patching s390 DASD-enabled kernels within maintenance windows
• Monitor for kernel oops reports referencing dasd_alias_get_start_dev
• Restrict untrusted local access on production s390 systems until updated