Exploitation of null references in the Linux kernel
It was recently announced that researchers from the Google Project Zero team have developed a method to exploit vulnerabilities in the Linux kernel caused by the dereferencing of the NULL pointer.
Until now, kernel problems related to NULL pointer dereferencing have not received due attention , as it was considered unrealistic to turn such problems into attacks leading to privilege escalation or execution of one's own code (mapping unprivileged processes to the lower region of the address space is prohibited).
As a general rule, such errors lead to the generation of oops warnings by the kernel, after which the problematic tasks are completed and the state is restored without the need to stop the system.
The new attack method is based on the handling of "oops" states , which can result in an increase in the value of the reference counter (refcount), which in turn can cause the counter to overflow and release the memory associated with the refcount.
In this case, the exploitation is reduced to manipulations typical of use-after-free attacks (a situation arises where the reference count of the object becomes zero, memory is freed, but in fact there are working links pointing to to freed memory).
Currently, when the Linux kernel triggers a null dereference from within a process context, it generates an oops , which is distinct from a kernel panic. A panic occurs when the kernel determines that there is no safe way to continue execution and therefore must cease all execution. However, the kernel does not halt all execution during an oops; instead, the kernel attempts to recover as best it can and continues execution.
Dereferencing a NULL pointer is used here as a way to generate the "oops" state in a controlled manner. The problem is that it takes about 232 "oops" status calls to reach a 32-bit refcount overflow.
From a practical standpoint, it takes approximately eight days of continuous generation of out-of-place (OOP) states to perform an attack using the proposed exploit. If successful, the exploit allows you to execute your code at the kernel level.
The NULL pointer dereference used in the exploit was fixed in October, but since similar issues are not uncommon and were previously treated as bugs, not vulnerabilities, the developers will add general protection to the Linux kernel to prevent attacks that manipulate the generation of "oops."
In the case of a task, that means discarding the existing kernel stack and going directly to make_task_dead which calls do_exit. The kernel will also post to dmesg a "crash" log and a kernel trace showing what state the kernel was in when the error occurred. This may seem like an odd choice when memory corruption has clearly occurred; however, the intent is to make kernel bugs easier to detect and log under the philosophy that a running system is much easier to debug than a down one.
In particular , Kernel 6.2 includes changes to limit the maximum number of "oops" . After reaching the limit, which is set to 10 oops by default (you can change this using the oops_limit parameter if desired), the kernel will initiate a transition to a "panic" state, followed by a reboot, which will not allow the number of iterations required to reset refcount to zero.
It is also planned that the restriction will be transferred to previously released, but still supported kernel branches, as well as kernel packages of popular distributions.
Finally, if you are interested in learning more about this , you can find the details at the following link.