If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems
A few days ago the news was announced that it was a vulnerability detected in the kernel network subsystem Linux that allows, overwriting the contents of memory of the kernel, by manipulating network sockets in user space.
It is mentioned that the vulnerability (already cataloged under CVE-2023-42752) is classified as critical and could be used to allow an unprivileged user access to run your code at the kernel level.
About vulnerability CVE-2023-42752
As such, the detected fault It is caused by a change introduced in Linux kernel version 6.2, but it is mentioned that this change was also introduced in all supported LTS branches, so the vulnerability It also appears in older versions of supported stable branches of the kernel.
Hello,
I recently encountered an integer overflow in the Linux kernel, which leads to the kernel by allocating `skb_shared_info` in user space, which is exploitable on systems without SMAP protection from `skb_shared_info` contains references to function pointers.
I verified the existence of the vulnerability in both the main branch and v6.1.y, more versions may be affected (potentially all stable versions)
Regarding the causes of the problem, it is mentioned integer overflow is still due in the "alloc_skb" function of the Linux kernel, the cue is used to provide the memory allocation for the sk_buff (socket buffer) structure, which is used to store network packets.
The vulnerability can be exploited because an issue that causes an overflow occurs due to a lack of proper validation of the parameters received from the user used to calculate the buffer size. An attack by an unprivileged user requires access to create user namespaces, which may be provided, for example, in insulated containers.
Code screenshot
It is mentioned that: The `kmalloc_reserve` function rounds the size in `PAGE_SIZE << get_order(size);` in `kmalloc_size_roundup`. Since 'size' is 'unsigned int`, the rounding logic will make it 0 if the original value is larger, for example something like 0xffffded0. As a result, "data" will actually become `ZERO_SIZE_PTR`, which is 0x10 instead of 0. Since verification does not consider the case, so the kernel will continue processing "data" as if they were a pointer to the valid kernel.
Later, when the kernel tries to finalize the skb object in `__finalize_skb_around`, it has the code: `shinfo = skb_shinfo(skb);`, which is `skb->head+skb->end` where `skb->head` is 0x10 and `skb->end`
is a large size like 0xffffmed0. As a result, `shinfo` points to a userspace pointer.
It is worth mentioning that the vulnerability CVE-2023-42752 is local and cannot be exploited remotely over the network, since as we mentioned above, an attacker requires access to create user namespaces.
Back in 2010, I didn't realize that malicious users could set dev->mtu to arbitrary values. This mtu has since been limited to 0x7fffffff, but regardless of how large dev->mtu is, it doesn't make sense for igmpv3_newpack() to allocate more than IP_MAX_MTU and risk overflowing multiple skb fields
As a temporary solution It is recommended that the SMAP protection mechanism be enabled (Supervisor Mode Access Prevention) in the kernel, which blocks the issue.
With regards to solution to the problem as such, this has already been patched and distributed in the fixes that block the vulnerability in the different versions with kernel support, it is mentioned that the changes were accepted in the stable branches of the kernel on September 5.
Finally, for the interested in tracking the correction of the vulnerability, you can do so on the pages of the different distributions: Debian, Ubuntu, Gentoo, RHEL,fedora and SUSE/openSUSE.You can check the details of the vulnerability in the following link