CVE-2024-53128

What it actually does

When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, object_is_on_stack() produces incorrect results because the obj pointer retains KASAN tags while the stack pointer does not, causing false stack-object detection failures and debug-object warnings under CONFIG_DEBUG_OBJECTS.

Why it matters to the business

Kernel boot or task-management operations on affected Linux distributions may emit spurious warnings and trigger debug-object checks, increasing operational noise and potentially masking real issues during development, testing, or production kernel initialization.

How an attack unfolds

An attacker with local access can trigger kernel paths that call debug_object_init_on_stack (for example during workqueue or kthread initialization) to surface the mismatched tagged-pointer check; the resulting false warning does not itself provide code execution but can be used to generate noise or interfere with debugging tooling in environments where the listed threat actors have already been observed targeting other Linux kernel memory issues.

How to fix it

Upgrade Linux kernel packages to a version containing commit 82e813b12b10ff705f3f5d600d8492fc5248618b; for Xen on Ubuntu 14.04 LTS apply the fixed package version 4.4.2-0ubuntu0.14.04.5 or later; rebuild with CONFIG_KASAN_SW_TAGS=n if the tagged-pointer configuration is not required.

How to confirm the fix worked

After patching, verify that object_is_on_stack() comparisons succeed without tag-induced mismatches by running kernel self-tests that exercise debug_object_init_on_stack and confirming the absence of the ODEBUG warning string in dmesg.

Typical attack path

1. Obtain local execution context on an affected kernel build with KASAN_SW_TAGS and DEBUG_OBJECTS enabled
2. Trigger a code path that annotates an object on the stack (e.g., schedule_hrtimeout or kthread_bind)
3. Observe the ODEBUG warning indicating the object is reported as not on stack due to tag mismatch
4. Use the warning noise to complicate forensic analysis or to probe for additional kernel surface

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for the exact ODEBUG warning text that references an object address that is NOT on stack but annotated; correlate with process names such as swapper/0 or init_rescuer during early boot.

• ODEBUG: object .* is NOT on stack .* but annotated
• WARNING: CPU: .* PID: .* at lib/debugobjects.c:557 __debug_object_init
• debug_object_init_on_stack+0x30/0x3c
• schedule_hrtimeout_range_clock+0xac/0x26c

What your security team should do

• Prioritize patching Ubuntu Xen 14.04 LTS systems and any custom kernels built from the affected git tree within the next maintenance window
• Enable kernel logging of debug-object warnings to SIEM for ongoing monitoring until patches are deployed
• Review kernel build configurations to disable KASAN_SW_TAGS on production systems where the feature is unnecessary