{"uuid": "bafb1509-1472-40ac-b457-671de2fb6117", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2023-29360", "type": "seen", "source": "https://t.me/hacking_Attack/117540", "content": "ucture\u2019s storage to the virtual memory, sets the buffer VA that the MDL describes in its header, but does not initialize the PFN array describing the physical memory that will be used for the buffer. \n\nIn fact, it should be coupled with a second API call that is responsible for establishing this array, thus acquiring the correct physical memory to describe it.\n\nThe second API\u2014MmProbeAndLockPages\u2014 first probes the buffer VA described by the MDL\u2014i.e., it will check if this buffer VA can be accessed\u2014in case the the AccessModeparameter is set to UserMode. \n\nNext, this function locks the physical pages, making them unable to be paged, reallocated, or freed while setting the access operation (read and/or write).\n\nLet\u2019s describe what the\u00a0probing consists of: \n\nAs already described, new MDLs can be created to get the physical description of a given virtual address\u2019s buffer already in use by the OS and potentially to directly interact with the physical memory associated with this buffer. \n\nIn particular, it can be used against various data already in use at the kernel level. \n\nThis is a problem when the MDL parameters come from the user-land (for instance, because that user-land process aims to perform a DMA operation), for example, through a\u00a0DeviceIO\u00a0control message made to a driver. \n\nIndeed, if the user-land process passes in kernel pointers for the creation of the MDL, and is then able to interact with it, that means this user-land process would be able to interact with kernel data. \n\nAs a consequence, the user/kernel barrier is broken. To avoid this problem, the\u00a0probing\u00a0simply checks that the buffer VA in the MDL is not in the land, by checking that the address is not superior to 0x7FFFFFFF0000. Explaining The Root Cause The FsAllocAndLockMdlfunction is reachable through a DeviceIOcontrol message with code 0x2f0408. In particular, the parameters for the MDL creation are directly taken from the user-supplied SystemBuffer. \n\nAs the AccessModeparameter of MmProbeAndLockPageswas not correctly set to UserMode, no probing of the MDL occurs. As a consequence, the user can create a MDL pointing to critical kernel data.\n\nAs CVE-2023-29360 was exploited, it means there is a way for the user to interact later with the arbitrarily created MDL, especially to directly modify the kernel data pointed at by it. \n\nIn particular, it appears that a second DeviceIOcontrol message with code 0x2f0410, permits to map the previously created MDL\u2019s physical memory directly in the user-land process\u2019s memory, inside a variable with read and write access. \n\nThis mapping is realized through the MmMapLockedPagesSpecifyCacheAPI. As a consequence, accessing this variable as a pointer allows the physical pages used in the MDL to be accessed and modified directly. Exploiting The Vulnerability One approach to exploit CVE-2023-29360 is to first obtain a MDL describing the kernel VA where the current process privileges are defined (the kernel VA being simply obtained through a\u00a0NtQuery\u00a0leak), using the first\u00a0DeviceIO\u00a0control message. Subsequently, this MDL is mapped through the second\u00a0DeviceIO\u00a0control message. \n\nAs a consequence, the values located at the kernel VA, where the current process privileges are defined are now directly accessible and modifiable in the current process\u2019s virtual memory. \n\nThe process can now freely modify its own privileges and achieve privilege escalation, for example by getting the SeDebugPrivilege.\n\nThe following steps highlight how the identified exploit approach works:\n\n1. The exploit process is launched. After launching, the memory layout is as follows:\n\nhttps://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgB9zvaAemOn7u2xQxJfcUwfroQcEwaZmLQDn6u4O0UDlMZFf1V6VUe9IJp8PvgZeQExkXgJ8BOgCmsmu1zb_0bhaer7YZ0r6uNI3xVTmQWWpTIWTyjz_AVDztFhaGXMgtBSiULsr[...]", "creation_timestamp": "2026-09-01T20:00:52.225171Z"}