kernel memory use after free

“CWE-466 Return of pointer value outside of expected range
CWE-467 Use of sizeof() on a pointer type
CWE-468 Incorrect pointer scaling
CWE-469 Use of pointer subtraction to determine size
CWE-476 NULL pointer dereference
CWE-587 Assignment of a fixed addres to a pointer
CWE-588 Attempt to access child of a non-structure pointer
CWE-763 Release of invalid pointer or reference
CWE-822 Untrusted pointer derefernece
CWE-823 Use of out-or-range pointer offset
CWE-824 Access of uninitialized pointer
CWE-825 Expired pointer dereference”
“Memory management subsystem, Heap Memory:
Use after free”

“CWE-226 Sensitive information in resource not removed before reuse
CWE-454 External initialization of trusted variables or data stores
CWE-455 Non-exit on failed initialization
CWE-459 Incomplete cleanup” "GCC, plugins, Stack memory:
Uninitialized variables: "
"GCC, plugins, Stack memory:
Uninitialized variables: "
Stack memory: Uninitialized variables:
“CWE-73 External control of file name or path
CWE-410 Insufficient resource pool
CWE-763 Release pointer or reference
CWE-772 Missing release of resource after effective lifetime
CWE-826 Premature release of resource during expected lifetime
CWE-908 Use of uninitialized resource
CWE-909 Missing initialization of resource
CWE-911 Improper update of reference count
CWE-920 Improper restriction of power consumption” “Kernel Memory:
Isolation of critical code”

“CWE-120 Buffer copy without checking size of input (”“classic buffer overflow)
CWE-121Stack-based bufer overflow
CWE-122 Heap-based buffer overflow
CWE-123 Write-what-where condition
CWE-124 Buffer underwrite (”“buffer underflow”“)
CWE-125 Out-of-bounds read
CWE-126 Buffer over-read
CWE-127 Buffer under-read
CWE-129 Improper validation of array index
CWE-131 Incorrect calculation of buffer size
CWE-786 Access of memory location before start of buffer
CWE-787 Out-of-bounds write
CWE-788 Access memory location after end of buffer
CWE-805 Buffer access with incorrect length value” Stack memory: Stack overflow:

“CWE-73 External control of file name or path
CWE-410 Insufficient resource pool
CWE-763 Release pointer or reference
CWE-772 Missing release of resource after effective lifetime
CWE-826 Premature release of resource during expected lifetime
CWE-908 Use of uninitialized resource
CWE-909 Missing initialization of resource
CWE-911 Improper update of reference count
CWE-920 Improper restriction of power consumption” “Kernel Memory:
Kernel corruption of user space memory”

Kernel configuration subsytem:attributes Kernel configurations Key Configuration Dependencies : notes Architecture Dependencies Safety Default Setting Description Related CVEs Related ExploitDB Scripts Weaknesses/ Limitations Supported Kernel Versions General Guidelines Performance Impact Suggested for Instance Types Kernel doc references
This column indicates the context for each kernel configuration (see column H), indicating the relevant Linux kernel subsystem(s) and potential vulnerabilty which is addressed by the configuration setting. Kernel configurations are features which may be enabled or disabled in the kernel build. The features listed below are chosen as candidates to support safety goals in safety critical systems. The integrator may consider these features in a specific use case and judage (based on documentation and source code) whether or not each of these features is relevant to support the safety of the system under consideration. Dependencies change from version to version, and it is the developers’ responsibility to check. “Architecture dependencies can be derived by using http://get_feat.pl/
For example, to list features supported by arm64 architecture, run: get_feat.pl --arch=arm64.
Or to list features supported by all architectures in REST format, run: get_feat.pl rest.
Or to list features supported by currently running kernel, run: get_feat.pl current.” Each setting can either be enabled (set to “Y”) or disabled (“N”). This column indicates the desired setting for safety features to be supported. Basic description of each kernel configuration is documented in the Kernel Driver Database https://cateee.net/lkddb/web-lkddb/ which is built automatically from kernel sources. Here we provide additional clarifications to help a system integrator understand how each kernel configuration may be relevant to support safety requirments in a specific use case. The CVEs related to this configuration. The links to well-known and verified scripts for exploit the kernel when this configuration is not enabled. Weaknerses and limitations for each kernel feature are addressed, to help the integrator in considering the broader context of its adtoption. See Linux Kernel Driver Database https://cateee.net/lkddb/web-lkddb/ for each kernel configuration for the most up-to-date information on supported kernel versions for each kernel configuration. “The scope of this documentation is to identify kernel configurations which support features that are potentially useful to enhance safety in specific use cases. The document should help the integrator focus on a relevant subset of the thousands of available kernel configurations.
It should be clear that this document is not a ““plug and play”” list, and it is up to the integrator to use the content as a baseline to help focus the search for relevant kernel configurations.” Performance impact on boot time and runtime. Performance of boot might affect the live migration and fail over and recovery time. Suggestions on configure it on host and/or guest OS, with considerations of performance and isolation brought by VMs. Links to useful kernel documentation which may be helpful for the integrator in evaluating the relevance of any kernel configuration for a specific use case.
“Memory management subsystem, Heap Memory:
Use after free” CONFIG_SLAB_FREELIST_RANDOM CONFIG_SLAB || CONFIG_SLUB Requires architecture support for SLUB (unqueued) or SLAB memory allocator. Y "Randomize kernel data structures to help make common kernel exploits more difficult. Linux freelist is a data structure (FIFO queue) which organizes free heap memory.
During heap overflow attacks, the attacker cannot predict the heap state since the heap may be fragmented into multiple memory areas. In order to exploit a heap overflow, the attacker will need to control the heap state. This can be done by repeated allocations of the same size, and leveraging the predictability of the freelist management algorithm to follow future allocations. For an example, see Job Oberheide’s blog.
To help minimize the risk of heap overflow attack, this configuration setting supports freelist randomization. " The randomization algorithm is carefully chosen to balance sufficient randomization so that the basic heap overflow attack is more difficult, but at the same time avoiding performance impact due to increased time for memory searches in randomized memory. Therefore there are no guarantess that heap overflow attacks will be completely blocked. However, enabling this configuration setting (with negligible performance impact expected) should reduce the risk of heap overflow attacks. 4.7–4.20, 5.0–5.17 The integrator in a particular system should confirm: 1. Performance impact matches expectations and is negligible. 2. The risk of heap overflow attacks is reduced to an acceptable level. A little bit, could be negligible. Suggested for Host OS, Guest OS and Cloud Native Scenarios. https://kernel.org/doc/Documentation/admin-guide/hw-vuln/spectre.rst
“Memory management subsystem, Heap Memory:
Use after free” CONFIG_SLAB_FREELIST_HARDENED CONFIG_SLAB || CONFIG_SLUB Requires architecture support for SLUB (unqueued) or SLAB memory allocator. Y “This option added XOR operations on SLAB freelist pointers for additional protection.
This feature makes the system much less vulnerable to freelist pointer exploits (or heap memory management issues due to freelist pointer overwrites) because an attacker needs to expose both the random value and the location of the freelist pointer. Continuous enhancements to more recent kernel versions help to make this feature much more capable of protecting heap memory from overflow exploits.” It should be noted that some slab implementations have more sanity-checking than others. 4.14–4.20, 5.0–5.17 The integrator in a particular system should confirm: 1. Performance impact matches expectations and is neglible. 2. The risk of heap overflow attacks (or errors due to heap overflow overwirtes) is reduced to an acceptable level. 3. The slab implementation on the specific architecture has undergone sufficient sanity testing for safety critical applications. If not, additional testing may be mandated for safety qualification. No performance impact on boot time, by adding XOR operations on SLAB freelist pointers, might introduce negligible performance impact on runtime. Suggested for Host OS, Guest OS and Cloud Native Scenarios. https://outflux.net/blog/archives/category/security/
“Memory management subsystem, Heap Memory:
Use after free” CONFIG_SLAB_MERGE_DEFAULT CONFIG_SLAB || CONFIG_SLUB None N Disabling this option will prevent slab caches from being merged by the kernel when they share similar charactersitics. This makes heap overflow exploits much more difficult, since such an exploit will usually only be able to overwrite objects in the same cache. Enabling this setting reduces kernel fragmentation, so that the integrator should check the impact on memory allocation due to disabling 4.13–4.20, 5.0–5.17 Recommendation from Kees Cook https://www.openwall.com/lists/kernel-hardening/2017/06/19/33 A little bit at runtime, could be negligible. Suggested for Host OS, Guest OS and Cloud Native Scenarios.
“Memory management subsystem, Heap Memory:
Use after free” CONFIG_SHUFFLE_PAGE_ALLOCATOR SLAB_FREELIST_RANDOM, ACPI_NUMA None Y SLAB_FREELIST_RANDOM (see line 22 above) is limited to reducing predictability of the freelist data strucutre, and this configuration extends the randomization to the page allocator free memory ists. Thus these 2 configurations complement each other and are recommended in tandem. Page allocator randomization can help to improve cache utilization, but may have a negative performance impact in systems which do not support cache. Therefore by default it will be enabled only after the runtime system detects a direct-mapped mememory s