CVE-2024-50133

What it actually does

NULL pointer dereference in stack_top() when vdso pointer is NULL for tasks such as kthreads that lack a vDSO mapping, resulting in kernel crash.

Why it matters to the business

System instability and potential kernel panics during testing or task creation on LoongArch systems, disrupting operations and requiring reboots.

How an attack unfolds

An attacker or automated test triggers arch_pick_mmap_layout or similar paths that invoke stack_top() on a kthread or other task without vDSO, dereferencing the NULL pointer and causing a crash; listed threat actors in Linux kernel campaigns could leverage similar memory issues for denial of service.

How to fix it

Update the Linux kernel to commit a67d4a02bf43e15544179895ede7d5f97b84b550 or later stable release containing the fix; apply available package updates for affected distributions.

How to confirm the fix worked

Verify kernel version includes the referenced commit, reproduce kunit_vm_mmap scenarios without triggering the crash, and confirm absence of stack_top NULL dereference in logs.

Typical attack path

1. Create or schedule a kernel thread or test task without vDSO mapping
2. Invoke mmap layout selection that calls stack_top()
3. Dereference NULL vdso pointer leading to oops or panic

How to detect it

Inspect kernel logs and dmesg for call traces containing stack_top+0x58/0xa8 combined with arch_pick_mmap_layout and kunit functions; review audit logs for unexpected kthread or mmap activity on LoongArch.

• stack_top+0x58/0xa8
• arch_pick_mmap_layout+0x164/0x220
• kunit_vm_mmap_init+0x108/0x12c
• usercopy_test_init+0xbc/0x25c

What your security team should do

• Prioritize kernel updates on all LoongArch systems within standard maintenance windows
• Monitor for kernel oops reports mentioning stack_top during testing workloads
• Restrict unprivileged access to kunit or similar diagnostic interfaces until patched