The Linux kernel has resolved a vulnerability in the sched/task_stack module, specifically with the object_is_on_stack() function. This vulnerability may produce incorrect results when both the CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK configurations are enabled. Such a discrepancy can lead to incorrect stack object detection, and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled.
In this post, we'll discuss the details of the exploit, provide a code snippet that demonstrates the issue, and include links to the original references.
Code Snippet
The vulnerability is present in the object_is_on_stack() function, which is outlined in the following example, causing a warning to be triggered:
ODEBUG: object 3eff800082ea7bb is NOT on stack ffff800082ea000, but annotated.
------------[ cut here ]------------
WARNING: CPU: PID: 1 at lib/debugobjects.c:557 __debug_object_init+x330/x364
For the complete code, you can find it here.
Exploit Details
When using CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK, the object_is_on_stack() function may produce incorrect results. This issue arises because the obj pointer has tags while the stack pointer doesn't. As a result, the function returns false positives when detecting whether an object is on the stack or not.
This discrepancy can cause warnings if CONFIG_DEBUG_OBJECTS is also enabled. In turn, it's possible that the kernel may face unexpected behavior or other potential issues as it moves forward with operations.
Original References
The issue was initially reported by Andrey Konovalov and was resolved by the Linux kernel commit 3eef08a, which contains the fix for the vulnerability. It's important to keep your kernel up-to-date to receive patches like these that address security issues.
Conclusion
For those running Linux, staying up-to-date with kernel updates is crucial for addressing vulnerabilities like this one in the sched/task_stack module. By understanding the exploit details and ensuring your configuration is properly adjusted, you can be better prepared to safeguard your systems against potential issues.
Timeline
Published on: 12/04/2024 15:15:12 UTC
Last modified on: 12/19/2024 09:39:53 UTC