Memory management method and electronic device

Abstract

The application discloses a memory management method and electronic equipment, and relates to the technical field of system security. The method comprises the following steps: obtaining a kernel native heap memory allocation function and a heap memory release function; obtaining a vulnerability object allocation function; monitoring the kernel heap memory allocation function and the vulnerability object allocation function through dynamic extension of a kernel program, collecting memory pre-allocation data according to a monitoring result, and performing a write operation on the memory; comparing double-boundary memory write operation parameters with the memory pre-allocation data, and detecting heap overflow of the memory write operation according to a comparison result; and in response to a detection result of the heap overflow of the memory write operation being failed, releasing an original memory application through the heap memory release function, and reallocating the memory application through a dynamic cache pool algorithm. The application can block privilege escalation and kernel crash caused by memory heap overflow in real time, solve the problems of memory fragmentation and defense lag, and significantly improve the continuous guarantee capability of a key business scenario.

Description

Technical Field

[0001] This application relates to the field of system security technology, and in particular to a memory management method and electronic device. Background Technology

[0002] As a core component of modern operating systems, the Linux kernel is widely used in servers, cloud computing, embedded devices, and mobile terminals. The kernel heap memory management functions are responsible for dynamically allocating and releasing heap memory, which is a core function of kernel runtime. However, the complexity of the heap memory management functions makes them vulnerable to heap overflow attacks or program errors.

[0003] Heap overflow that overwrites the next adjacent memory block can affect the normal execution of a program. If the next adjacent heap block stores function pointers, it can hijack the program's execution flow and elevate privileges to the highest-privileged user. If the next adjacent heap block contains critical kernel data structures, it may lead to data corruption, causing kernel crashes or even complete system unavailability, seriously threatening system security and reliability. Summary of the Invention

[0004] This application provides a memory management method and electronic device. The method includes: obtaining the kernel's native heap memory allocation function and heap memory deallocation function through dynamically extended kernel programs; obtaining the vulnerability object allocation function; monitoring the kernel heap memory allocation function and vulnerability object allocation function through a probe tool of the dynamically extended kernel program, and collecting memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value; performing a write operation on the memory; comparing the double-boundary memory write operation parameters with the memory pre-allocation data, wherein the double-boundary memory write operation parameters include the length of the data written to memory and the destination memory address; detecting heap overflow of the memory write operation based on the comparison results; and, in response to the heap overflow detection result of the memory write operation failing, releasing the original memory allocation through the heap memory deallocation function and reallocating the memory allocation through a dynamic cache pool algorithm. This application can block privilege escalation and kernel crashes caused by memory heap overflows in real time, while simultaneously solving the problems of memory fragmentation and defense lag, significantly improving the continuous assurance capability of critical business scenarios.

[0005] This application provides a memory management method applied to a server processor, the method comprising:

[0006] Obtain kernel native heap memory allocation and deallocation functions by dynamically extending kernel programs;

[0007] Obtain the vulnerability object allocation function;

[0008] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0009] Perform a write operation to memory;

[0010] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0011] Heap overflow detection for memory write operations is performed based on the comparison results;

[0012] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0013] This application also provides a server, the server including a processor, the processor being used for:

[0014] Obtain kernel native heap memory allocation and deallocation functions by dynamically extending kernel programs;

[0015] Obtain the vulnerability object allocation function;

[0016] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0017] Perform a write operation to memory;

[0018] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0019] Heap overflow detection for memory write operations is performed based on the comparison results;

[0020] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0021] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements a memory management method, the method comprising:

[0022] Obtain kernel native heap memory allocation and deallocation functions by dynamically extending kernel programs;

[0023] Obtain the vulnerability object allocation function;

[0024] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0025] Perform a write operation to memory;

[0026] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0027] Heap overflow detection for memory write operations is performed based on the comparison results;

[0028] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0029] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing a memory management method when executing the computer program, the method comprising:

[0030] Obtain kernel native heap memory allocation and deallocation functions by dynamically extending kernel programs;

[0031] Obtain the vulnerability object allocation function;

[0032] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0033] Perform a write operation to memory;

[0034] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0035] Heap overflow detection for memory write operations is performed based on the comparison results;

[0036] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0037] This application utilizes a method that includes: obtaining kernel native heap memory allocation and deallocation functions through dynamically extended kernel programs; obtaining vulnerability object allocation functions; monitoring these functions using probe tools within the dynamically extended kernel programs; collecting pre-allocated memory data based on the monitoring results, including one or more of the following: the starting address of pre-allocated memory, the size of the memory space, and the location of the memory sentinel value; performing a write operation on the memory; comparing the double-boundary memory write operation parameters with the pre-allocated memory data, including the length of the data written and the destination memory address; detecting heap overflows in the memory write operation based on the comparison results; and, in response to a failed heap overflow detection, releasing the original memory allocation through the heap memory deallocation function and reallocating the memory allocation using a dynamic cache pool algorithm. This application can effectively prevent privilege escalation and kernel crashes caused by heap overflows in real time, while also addressing memory fragmentation and defense lag issues, significantly improving the continuous assurance capabilities for critical business scenarios.

[0038] This application's technical solution achieves dynamic monitoring and proactive defense against heap overflow attacks without modifying the Linux system kernel source code. Through sentinel canary values ​​and double boundary checks, it enables real-time detection and blocking of heap overflows, completely preventing privilege escalation and system crashes. It reduces lock contention through a per-CPU hash table; controls memory fragmentation by dynamically defining the cache range, making it suitable for production environments; based on the kernel function call mechanism, it requires no kernel source code modification and supports Linux versions 5.8 and above; and it precisely locates vulnerable object allocation functions through processes and identifiers, enabling strict defense only for high-risk memory requests, avoiding indiscriminate interference with normal memory allocation, and further reducing system performance overhead. Attached Figure Description

[0039] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 A first flowchart of a memory management method provided in an embodiment of this application;

[0041] Figure 2A second flowchart of a memory management method provided in an embodiment of this application;

[0042] Figure 3 A third flowchart of a memory management method provided in an embodiment of this application;

[0043] Figure 4 A structural diagram of a memory management device provided in an embodiment of this application;

[0044] Figure 5 Exemplary systems provided for embodiments of this application that can be used to implement the various embodiments of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0046] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0047] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0048] Linux kernel heap overflow is a core threat to kernel security. Attackers can achieve privilege escalation or system crashes by tampering with function pointers and destroying critical data structures. Relevant defenses mainly include:

[0049] Kasan: a dynamic memory error detector. Kasan is a shadow byte maintained by the kernel for every 8 bytes of contiguous memory. It is used to mark the state of the memory (such as whether it is valid or has been freed). During code execution, every memory access will check whether the corresponding shadow memory value is valid.

[0050] Oops or Panic: Oops is the kernel error reporting mechanism, which is triggered when the kernel encounters an error that can be caught but cannot be safely recovered from (such as null pointer dereference or memory out-of-bounds access). Oops will terminate the current process or thread and attempt to keep the system running, but the kernel state may be corrupted. Panic, on the other hand, is an emergency mechanism when the kernel encounters an unrecoverable fatal error (such as damage to critical data structures). It will immediately stop all operations, freeze the system, and output error information, requiring a manual reboot to recover.

[0051] Random memory allocation: Allocate a random free memory object in a larger random memory cache pool slab, which disrupts the attacker's prediction of the memory layout, making it difficult to accurately trigger the overflow and increasing the difficulty of privilege escalation.

[0052] However, using Kasan requires inserting a large amount of detection code during compilation, and 1 / 8 of the memory is used for shadow memory, which leads to a decrease in runtime system performance and is not suitable for production environments.

[0053] Using Oops or Panic only triggers logging or system restart after a heap overflow occurs, lacking proactive defense capabilities and unable to prevent the overflow from spreading or restore the system in the first instance.

[0054] The random memory allocation method has the following drawbacks: (1) Kernel intrusion (i.e., modification of kernel source code): It relies on the "error injection mechanism" (bpf_override_return) to modify the return value of kernel functions, which may interfere with the normal kernel process; and it requires the addition of helper functions, i.e., modification of kernel source code; (2) Memory fragmentation: Unrestricted selection of larger slab caches (e.g., kmalloc-64 can be randomly upgraded to kmalloc-8192), long-term operation will aggravate memory fragmentation and affect system performance; (3) Passive defense: It only increases the difficulty of attack by randomization, and cannot actively detect and block overflow behavior. If the attacker sprays a large number of heaps, it may still hit the target; (4) Although it increases the difficulty of privilege escalation for attackers, it cannot prevent overflow from causing the destruction of key kernel data structures and causing system crash.

[0055] Therefore, there are still many problems in the defense against Linux kernel heap overflows. For example, using Kasan can lead to a serious decline in system performance; using Oops or Panic lacks the ability to actively defend; and using random allocation of larger memory relies on error injection, requires modification of the kernel source code, can exacerbate memory fragmentation, is a passive defense, and cannot avoid the system crash that heap overflows may cause.

[0056] Embodiments of this application provide a memory management method, such as... Figure 1As shown, the method is applied to the server's processor, and the method includes:

[0057] The processor obtains the kernel's native heap memory allocation and deallocation functions by dynamically extending the kernel program;

[0058] Obtain the vulnerability object allocation function;

[0059] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0060] Perform a write operation to memory;

[0061] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0062] Heap overflow detection for memory write operations is performed based on the comparison results;

[0063] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0064] Understandably, this application provides a Linux kernel heap overflow defense method based on EBPF programs: it achieves non-intrusive monitoring and proactive blocking of kernel heap memory operations without modifying the kernel source code or relying on error injection; it achieves real-time interception of memory heap overflows through proactive detection (rather than passive mitigation) based on randomization defense; it solves the memory fragmentation problem caused by randomization through fine-grained cache management; and it avoids indiscriminate defense against normal memory allocation and reduces system performance loss through precise vulnerability object allocation function feature localization.

[0065] Heap overflow refers to the phenomenon where, during dynamic memory allocation (i.e., heap memory allocation), a program fails to properly verify data boundaries, resulting in data being written beyond the memory range of the allocated heap block and overwriting adjacent memory areas. In kernel mode, heap overflow is far more harmful than in user mode because attackers can use it to tamper with kernel data structures, hijack control flow, or escalate privileges to the highest level.

[0066] Heap spraying is a method of overflowing a data structure by requesting a large amount of memory and then releasing it in the air to ensure that a certain memory layout can be obtained.

[0067] Memory fragmentation: This refers to the phenomenon where memory space is divided into a large number of non-contiguous small blocks, causing the system to be unable to satisfy large memory requests even though it has enough total memory.

[0068] The difference between overflow and privilege escalation: Overflow refers to out-of-bounds operation on memory; privilege escalation refers to a jump in privilege status. Overflow may cause system programs to crash, or it may lead to successful privilege escalation.

[0069] eBP is a programming framework that allows users to dynamically extend the functionality of the kernel without modifying the kernel source code or loading kernel modules.

[0070] Kernel probes (kprobe): Kernel probes are divided into two categories: kprobe and kretprobe. kprobe: Allows the insertion of a hook at the entry point of a kernel function. When the kernel executes this kernel function, it will first execute the registered hook function and then execute the original kernel function. kretprobe: Allows the insertion of a hook function when a kernel function has finished executing and is about to return. This hook function can capture the return value of the function, etc.

[0071] Embodiments of this application provide a memory management method, such as... Figure 2 As shown, the method is applied to the server's processor, and the method includes:

[0072] This application proposes a Linux kernel heap overflow defense method based on EBPF programs, which can block privilege escalation and kernel crashes caused by heap overflow attacks in real time. At the same time, it solves the memory fragmentation and defense lag problems of existing dynamic mitigation solutions, and significantly improves the continuity assurance capability of critical business scenarios.

[0073] Step S01: Configure kernel heap overflow defense service;

[0074] Configure the kernel heap overflow protection service, including:

[0075] Configure the start / stop control method for the kernel heap overflow defense service through the service manager. The start / stop control method for the kernel heap overflow defense service includes one or more of the following: manual start / stop, fault restart, and automatic startup.

[0076] Specifically, the defense function's start / stop control is achieved by configuring the defense service through the Linux system's service management tool, systemd, to implement three start / stop control methods: manual start / stop, fault restart, and automatic startup. The service configuration file code is as follows:

[0077] # / etc / systemd / system / heapdefense.service

[0078] [Unit]

[0079] Description=EBPF-based Kernel Heap Overflow Defense

[0080] [Service]

[0081] Type=simple

[0082] ExecStart= / usr / bin / heapdefense-ctl start / / Manually start

[0083] ExecStop= / usr / bin / heapdefense-ctl stop / / Manually stop

[0084] Restart=on-failure / / Restart after failure

[0085] RestartSec=3

[0086] [Install]

[0087] WantedBy=multi-user.target / / Starts automatically on boot

[0088] Step S02: Initialize the dynamically extended kernel program (EBPF);

[0089] Initialize the dynamically extended kernel program, including:

[0090] Define a hash table for memory allocation function metadata, set the key of the hash table to the pre-allocated memory address, and set the value of the hash table to a memory allocation function metadata structure. The memory allocation function metadata structure is used to record the size of the pre-allocated memory space and the location of the memory sentinel value.

[0091] Define a hash table for the characteristics of the vulnerability object allocation function. Set the key of the hash table to the process that allocated the vulnerability memory object, and set the value of the hash table to the characteristic structure of the vulnerability object allocation function. The characteristic structure of the vulnerability object allocation function is used to record the number of memory allocations, the process that allocated the vulnerability memory object, and the call stack information of the vulnerability object allocation function.

[0092] Specifically, based on the BPF_MAP_TYPE_PERCPU_HASH type hash table of the EBPF program, two core data structures are defined:

[0093] Define a memory allocation metadata hash table alloc_map, where the key is the address of the memory to be allocated, and the value is the memory allocation function metadata structure (alloc_meta structure). This structure is used to record the size of the memory allocation and the location where the sentinel Canary value should be placed.

[0094] structalloc_meta{

[0095] size_tsize; / / The actual memory size requested by the process

[0096] void *canary_addr; / / Storage address of the Canary value

[0097] };

[0098] struct{

[0099] / / Define a memory allocation metadata hash table: the key is the memory address to be requested, and the value is an alloc_meta structure, which is stored independently for each CPU;

[0100] __uint(type, BPF_MAP_TYPE_PERCPU_HASH);

[0101] __uint(max_entries, 65536);

[0102] __type(key, void*);

[0103] __type(value,structalloc_meta);

[0104] }alloc_mapSEC(".maps");

[0105] Define a hash table hole_ma to identify memory requests from vulnerable object allocation functions, enabling precise defense (non-vulnerable requests are allowed to proceed normally). The key is the process pid, and the value is the vulnerability object allocation function feature structure (hole_meta structure). This structure is used to record the number of memory allocations (count), the process pid, and the stackid identifier (used to characterize the vulnerability object allocation function and avoid misjudgment based on a single process pid).

[0106] struct hole_meta{

[0107] u64 count; / / Number of assignments

[0108] u64 pid; / / Process pid of the process that allocated the vulnerable memory object

[0109] u64 stackid; / / Get the current function call stack information through bpf_get_stackid and generate a unique stack identifier stackid;

[0110] };

[0111] struct {

[0112] / / Define a feature hash table for the vulnerability object allocation function: the key is the process pid, and the value is a hole_meta structure, stored independently for each CPU;

[0113] __uint(type, BPF_MAP_TYPE_PERCPU_HASH);

[0114] __uint(max_entries, 65536);

[0115] __type(key, u64);

[0116] __type(value, struct hole_meta);

[0117] } hole_map SEC(".maps");

[0118] Step S03: Obtain the kernel's native heap memory allocation and deallocation functions by dynamically extending the kernel program.

[0119] The kernel's native heap memory allocation function kmalloc and heap memory deallocation function kfree are the ways the Linux kernel allocates and releases heap memory.

[0120] Step S031: Determine the proxy functions for the kernel native heap memory allocation function and heap memory deallocation function respectively by using the kernel function call mechanism of dynamically extended kernel programs;

[0121] The kernel native heap memory allocation function and heap memory deallocation function are obtained through proxy functions of the kernel native heap memory allocation function and heap memory deallocation function, respectively.

[0122] Specifically, by non-intrusively injecting custom proxy functions bpf_proxy_kmalloc() and bpf_proxy_kfree() into the kernel through the kernel function call (kfunc) mechanism, EBPF programs can indirectly call the kernel's native heap memory allocation function kmalloc() and heap memory release function kfree() through the injected proxy functions without modifying the kernel function return values. Compared to directly adding kernel functions, this method is dynamic and does not require modification of the kernel source code itself. It only requires registering the functions as kernel function call mechanisms (kfunc) through specific macros (such as BTF_ID_FLAGS).

[0123] Define a BTF set and declare the kernel functions that EBPF can call:

[0124] BTF_SET_START(bpf_kfunc_set)

[0125] BTF_ID_FLAGS(func,bpf_proxy_kmalloc, KF_ACQUIRE | KF_RET_NULL)

[0126] BTF_ID_FLAGS(func, bpf_proxy_kfree, KF_RELEASE)

[0127] BTF_SET_END(bpf_kfunc_set)

[0128] Register the kernel function call (kfunc) mechanism to the kernel:

[0129] static int __init init_bpf_mem(void)

[0130] {

[0131] return-register_btf_kfunc_set(BPF_PROG_TYPE_SYSCALL,&bpf_kfunc_set);

[0132] }

[0133] By using the register_btf_kfunc_set() interface provided by the kernel, the above BTF set is registered as an EBPF program callable function of system call type, thereby realizing the dynamic injection of kernel native heap memory allocation functions and heap memory deallocation functions.

[0134] Step S04: Obtain the vulnerability object allocation function;

[0135] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions. Based on the monitoring results, we can collect memory pre-allocation data, which includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0136] Step S041: Monitor the vulnerability object allocation function using a probe tool that dynamically extends the kernel program, obtain the vulnerability allocation point metadata based on the monitoring results of the vulnerability object allocation function, and store the vulnerability allocation point metadata in the vulnerability object allocation function feature hash table.

[0137] The metadata of the vulnerability allocation point includes the number of memory allocations, the process that allocated the vulnerable memory object, and the stack identifier generated by the function call stack information of the vulnerability object allocation.

[0138] Specifically, the vulnerability object allocation function is monitored and its metadata is stored: BPF_MAP_TYPE_PERCPU_HASH (processor-independent hash table) is used to store metadata, avoiding CPU lock contention issues in multi-processor systems; the vulnerability object allocation function is monitored using the EBPF program's probe tool kprobe (the vulnerability object allocation function needs to be analyzed based on the specific vulnerability, such as nft_set_elem_init() for CVE-2022-34918 and gsmld_open() for CVE-2024-36016), obtaining the vulnerability allocation point metadata, and recording the vulnerability allocation point metadata in the vulnerability object allocation function feature hash table hole_map. The key is the process PID that allocated the vulnerable memory object, and the value is a hole_meta structure. This structure stores the count of the number of times the vulnerable memory object was allocated, the process PID that allocated the vulnerable memory object, and the unique stack identifier stackid generated by obtaining the current function call stack information bpf_get_stackid.

[0139] Step S042: Monitor the kernel heap memory allocation function using a probe tool that dynamically extends the kernel program;

[0140] Determine whether the process and call stack information of the vulnerable memory object in the current memory allocation request are consistent with the process and call stack information of the vulnerable memory object in the hash table of the vulnerability object allocation function characteristics;

[0141] If the process and call stack information of the vulnerable memory object in response to the current memory request are consistent with the process and call stack information of the vulnerable memory object in the vulnerability object allocation function feature hash table, then the memory allocation function metadata is stored in the memory allocation function metadata hash table, where the memory allocation function metadata is memory pre-allocation data.

[0142] Specifically, the memory allocation function is monitored: the memory allocation function kmalloc() is monitored through the kernel function call mechanism kprobe of the EBPF program; by querying the memory allocation function hash table hole_map, it is determined whether the memory request comes from the vulnerable object allocation function. If the process pid and stackid of the current memory requesting process are consistent with the process pid and stackid in the vulnerable object allocation function feature hash table hole_map, it indicates that the memory request comes from the vulnerable object allocation function. Then, a Canary value is generated and injected, and metadata is saved.

[0143] Specifically, when the EBPF program monitors a call to the memory allocation function kmalloc, a random sentinel canary value is set at a specific location in the allocated memory block (e.g., between the end of the user-requested size and the padding area of ​​the actual slab allocation size), and the memory allocation function metadata is saved to the memory allocation function metadata hash table alloc_map. The memory allocation function metadata includes the starting address of the memory allocated, the size of the allocated memory, and the location where the sentinel value Canary should be placed.

[0144] The Canary value (which is a random number) is generated by combining kernel random numbers and process PID to enhance randomness and avoid the problem of predictable random values.

[0145] u64generate_canary(void*ptr,u64pid){

[0146] u64rand = bpf_get_prandom_u32(); / / Get a random number

[0147] u64pid_hash=bpf_hash_jit(ptr,sizeof(ptr))^pid; / / The allocated memory address and the hash of the process PID

[0148] return rand^pid_hash; / / Returns the final Canary value, which is process-specific and unpredictable.

[0149] }

[0150] Injection location: 8-byte padding between the user-requested size (size) and the actual slab allocated size (end) (e.g., if 56 bytes are requested, the slab memory manager will actually allocate 64 bytes, so Canary will inject at bytes 56-63), without occupying user memory;

[0151] void*bpf_proxy_kmalloc(size_tsize,gfp_tflags){

[0152] structalloc_metameta_data;

[0153] void*ptr=kmalloc(size+8,flags); / / Extra 8 bytes are used as the injection location for the canary;

[0154] u64canary = generate_canary(); / / Generate a Canary value

[0155] *(u64*)(ptr+size)=canary; / / Injects the Canary value into the specified location (for example, if the allocated memory starts at address 0xffffffffac1c4da0 and the allocated memory size is 56 bytes, then the Canary value will be placed at "0xffffffffac1c4da0+56=0xffffffffac1c4df6, and the size of the Canary value will not exceed 8 bytes)

[0156] meta_data.size = size;

[0157] meta_data.canary_addr=ptr+size;

[0158] bpf_map_update_elem(&alloc_map,&ptr,&meta_data); / / Stores the metadata of the memory allocation function in a hash table of memory allocation function metadata. The key of the hash table is the memory address allocated by the memory request, and the value is a structure variable meta_data of type alloc_meta of the memory allocation function. This structure is used to record the size of the memory allocation and the location where the Canary value should be placed.

[0159] return ptr;

[0160] }

[0161] Step S05: Perform a write operation on memory;

[0162] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0163] Heap overflow detection for memory write operations is performed based on the comparison results;

[0164] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0165] Step S051: Obtain double-boundary memory write operation parameters by dynamically extending the memory write operation function of the kernel program. The memory write operation parameters include the destination memory address and the length of the data to be written to memory.

[0166] The system determines whether the length of the data written to memory exceeds the pre-allocated memory size and whether the destination memory address intrudes into the memory sentinel value placement area.

[0167] If the length of data written to memory exceeds the pre-allocated memory size or the destination memory address intrudes into the memory sentinel value placement area, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0168] The method also includes:

[0169] If the length of the data written to memory is less than or equal to the size of the pre-allocated memory and the destination memory address does not intrude into the memory sentinel value placement area, then the memory request will be used to continue writing to the requested memory.

[0170] Specifically, the EBPF program's probe tool kprobe is used to monitor memory-writing functions such as memcpy() and copy_from_user() (the entry point for heap overflow attacks) to obtain the destination memory address dest and the length len of the data to be written; using the destination memory address dest as the key, the corresponding memory allocation function metadata is obtained from the memory allocation function metadata hash table alloc_map.

[0171] struct alloc_meta *meta_data = bpf_map_lookup_elem(&alloc_map,&dest);

[0172] Double boundary checks are performed: the length of the data written to memory is checked to see if it exceeds the pre-allocated memory size and whether the destination memory address intrudes into the memory sentinel value placement area; if the boundary checks pass, memory allocation is allowed; otherwise, the original memory allocation is released through the heap memory release function and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0173] First check: Length check: Checks whether the length len of the data written to memory exceeds the size of the memory requested by the user, recorded in the metadata hash table alloc_map of the memory allocation function;

[0174] if (len>meta_data->size) {

[0175] return -EFAULT;

[0176] }

[0177] Second check: Canary value area verification: Checks whether the destination memory address write range (char*)dest intrudes into the memory sentinel value placement area;

[0178] if ((char*)dest + len>meta->canary_addr) {

[0179] return -EFAULT;

[0180] }

[0181] If the above checks fail, the original memory is released and memory reallocation is triggered.

[0182] Step S052: Create a candidate set for the memory cache pool;

[0183] Create a candidate set for the memory cache pool, including:

[0184] The first cache pool is determined based on the memory allocation size;

[0185] Obtain the memory allocation count from the hash table of the vulnerability object's allocation function characteristics;

[0186] If the number of memory allocations exceeds the first threshold (50), the cache for which memory is requested is determined to be the second cache pool;

[0187] If the number of memory allocations is less than or equal to the first threshold, the cache for which the memory was requested is determined to be the third cache pool;

[0188] Generate a candidate set of cache pools based on the first cache pool, the second cache pool, and the third cache pool;

[0189] The target cache pool is determined from the candidate cache pool set, and memory requests are reallocated through the target cache pool.

[0190] Specifically, defining and randomizing the cache range, i.e. memory reallocation: when requesting heap memory using the kmalloc memory allocation function, the actual allocated memory is generally larger than the requested memory. For example, when requesting 5 bytes of memory, the kernel will allocate a free memory object from the kmalloc-8 cache (memory objects in kmalloc-8 are all 8 bytes); when requesting 9 bytes of memory, the kernel will allocate a free memory object from the kmalloc-16 cache (memory objects in kmalloc-16 are all 16 bytes).

[0191] A necessary step in heap spraying attacks is constructing an overlap between the vulnerable object and the attack payload object. To avoid this overlap, a free memory object can be randomly selected from the larger memory allocation function kmalloc cache. However, this easily leads to memory fragmentation, meaning the system has a large amount of memory but cannot allocate a large contiguous block. To avoid excessive memory fragmentation, a dynamic cache pool algorithm can be used to define the range of the kmalloc cache. The steps are as follows:

[0192] 1. Generate a candidate set for the cache pool:

[0193] Basic rule: For memory allocation size s, first determine its default slab cache C_default (e.g., if memory allocation s=56 → C_default=kmalloc-64);

[0194] Dynamic adjustment: Query the memory allocation count (count) in the feature hash table of the vulnerability object allocation function. If count > 50 (high-frequency allocation), the candidate cache pool is {C_default*1.5, C_default*2, C_default*2.5} (e.g., 56 bytes → {96, 128, 192}) to increase randomness. If the memory allocation count (count) in the feature hash table of the vulnerability object allocation function is ≤ 50 (low-frequency allocation), the candidate cache pool is {C_default*1.5, C_default*2} (e.g., 56 bytes → {96, 128}) to reduce memory fragmentation.

[0195] 2. Perform reallocation:

[0196] Randomly select one cache C_rand from the cache pool candidate set and call bpf_proxy_kmalloc to reallocate the memory allocation.

[0197] Step S06: Verify the release process of the original memory allocation;

[0198] Verify the deallocation process of the original memory allocation, including:

[0199] The metadata of the vulnerability object allocation function feature hash table and memory allocation function metadata hash table is deleted through the heap memory release function;

[0200] The metadata of the vulnerability object allocation function feature hash table and memory allocation function metadata hash table is deleted through the heap memory release function, including:

[0201] If metadata corresponding to the original memory request exists in the metadata hash table of the memory allocation function, then delete the metadata corresponding to the original memory request from the metadata hash table of the memory allocation function.

[0202] If the memory request being released belongs to the process that allocated the vulnerable memory object and that process has terminated, then the metadata corresponding to the original memory request in the vulnerability object's allocation function feature hash table is deleted.

[0203] Specifically, monitor memory release: use the kprobe tool of the EBPF program to monitor the heap memory release function, call the heap memory release function to clear the metadata of alloc_map and hole_map in a timely manner, and prevent alloc_map and hole_map hash tables from occupying too much memory;

[0204] void bpf_proxy_kfree(void *ptr){

[0205] / / Query alloc_map using ptr as the key. If the corresponding metadata exists in alloc_map, delete the entry.

[0206] if (bpf_map_lookup_elem(&alloc_map, ptr)){

[0207] bpf_map_delete_elem(&alloc_map,&ptr);

[0208] }

[0209] / / If the freed memory belongs to a vulnerability-associated process and that process has exited, then delete the corresponding metadata in the vulnerability object allocation function feature hash table.

[0210] u64 pid = bpf_get_current_pid_tgid()&0xFFFFFFFF;

[0211] if (bpf_map_lookup_elem(&hole_map, pid)){

[0212] if (bpf_get_current_comm(&comm, sizeof(comm)) == 0&&comm[0] == '\0'){

[0213] bpf_map_delete_elem(&hole_map,&pid);

[0214] }

[0215] }

[0216] }

[0217] Here, as Figure 3 As shown, the key point of this application is to propose a Linux kernel heap overflow defense method based on EBPF programs, which can block privilege escalation and kernel crashes caused by memory heap overflow attacks in real time, while solving the memory fragmentation and defense lag problems of existing dynamic mitigation schemes. The points to be protected in this application are: the method of starting and stopping the defense function; the EBPF program initialization process; the idea of ​​injecting memory management proxy functions without modifying the kernel source code; the method of storing metadata; the steps for locating the vulnerability object allocation function; the method of generating and injecting canary values; the method of real-time monitoring and double boundary checking of memory write operations; and the method of memory reallocation, etc.

[0218] In addition, the methods also include:

[0219] In response to issues with detecting memory heap overflows through dynamically extended kernel programs, memory heap overflows are prevented through secure coding and compilation hardening.

[0220] Preventing memory heap overflows through secure coding and compilation hardening includes:

[0221] Allocate memory and clear it using allocation functions that are zero-cleared and boundary-aware to prevent information leakage;

[0222] Validate the memory length input by the user;

[0223] Before releasing sensitive data, clear the sensitive data to prevent information leakage caused by residual memory.

[0224] Enable stack protection in kernel or compiler options to prevent ROP chains in some memory heap utilizations;

[0225] Perform boundary checks during compilation on kernel functions (such as memcpy, strcpy);

[0226] When compiling the kernel using Clang, runtime security mechanisms can be enabled to restrict indirect call targets;

[0227] Detect memory heap overflow using the KASAN detector and SLUBdebug;

[0228] First, compile and start the kernel for the KASAN detector;

[0229] The detector KASAN runs code that may trigger a heap overflow (such as loading modules or executing system calls).

[0230] When an illegal access occurs in code that has caused a memory heap overflow, the kernel stops the system and prints a detailed report.

[0231] If the KASAN detector cannot be started, quickly verify whether there is memory heap corruption by using SLUB debug mode=FZP;

[0232] Start the kernel with the SLUB debug mode parameter to trigger debugging. If an out-of-bounds error or a memory safety vulnerability occurs, the kernel will print a warning or stop the system.

[0233] Limit memory heap overflows using minimum privileges and MAC addresses;

[0234] Use capability mechanisms to restrict memory permissions (e.g., only network management capabilities are required, instead of full root);

[0235] Avoid exposing APIs with high-privilege root privileges;

[0236] Use a dedicated low-privilege user, disable privileged containers, and use user namespace mapping to root to a regular user;

[0237] Elevate privileges to root and enable security-enhanced Linux / application container policies;

[0238] Disable high-risk interfaces such as process tracing and performance events.

[0239] Through the above multi-layered defense, the difficulty for attackers to exploit heap overflows can be greatly increased, and high-risk vulnerabilities can be downgraded to denial-of-service (DoS) attacks, thereby ensuring system security.

[0240] The memory management method provided in this application can be improved and optimized in several ways without departing from the technical solution of this application, and these improvements and optimizations should also be considered within the scope of protection of this application.

[0241] The beneficial effects of the technical solutions provided in this application are:

[0242] This application can block privilege escalation and kernel crashes caused by memory heap overflow in real time, while solving the problems of memory fragmentation and defense lag, significantly improving the continuous assurance capability of critical business scenarios.

[0243] This application's technical solution achieves dynamic monitoring and proactive defense against heap overflow attacks without modifying the Linux system kernel source code. Through sentinel canary values ​​and double boundary checks, it enables real-time detection and blocking of heap overflows, completely preventing privilege escalation and system crashes. It reduces lock contention through a per-CPU hash table; controls memory fragmentation by dynamically defining the cache range, making it suitable for production environments; based on the kernel function call mechanism, it requires no kernel source code modification and supports Linux versions 5.8 and above; and it precisely locates vulnerable object allocation functions through processes and identifiers, enabling strict defense only for high-risk memory requests, avoiding indiscriminate interference with normal memory allocation, and further reducing system performance overhead.

[0244] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0245] Embodiments of this application also provide a server, the server including a processor, the processor being used for:

[0246] Obtain kernel native heap memory allocation and deallocation functions by dynamically extending kernel programs;

[0247] Obtain the vulnerability object allocation function;

[0248] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0249] Perform a write operation to memory;

[0250] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0251] Heap overflow detection for memory write operations is performed based on the comparison results;

[0252] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0253] The processor is used to: determine the proxy functions for the kernel's native heap memory allocation function and heap memory deallocation function respectively through the kernel function call mechanism of dynamically extending the kernel program;

[0254] The kernel native heap memory allocation function and heap memory deallocation function are obtained through proxy functions of the kernel native heap memory allocation function and heap memory deallocation function, respectively.

[0255] The processor is used to: monitor the vulnerability object allocation function through the probe tool of the dynamically extended kernel program, obtain the vulnerability allocation point metadata based on the monitoring results of the vulnerability object allocation function, and store the vulnerability allocation point metadata in the feature hash table of the vulnerability object allocation function;

[0256] The metadata of the vulnerability allocation point includes the number of memory allocations, the process that allocated the vulnerable memory object, and the stack identifier generated by the function call stack information of the vulnerability object allocation.

[0257] The processor is used to monitor kernel heap memory allocation functions through probe tools that dynamically extend kernel programs;

[0258] Determine whether the process and call stack information of the vulnerable memory object in the current memory allocation request are consistent with the process and call stack information of the vulnerable memory object in the hash table of the vulnerability object allocation function characteristics;

[0259] If the process and call stack information of the vulnerable memory object in response to the current memory request are consistent with the process and call stack information of the vulnerable memory object in the vulnerability object allocation function feature hash table, then the memory allocation function metadata is stored in the memory allocation function metadata hash table, where the memory allocation function metadata is memory pre-allocation data.

[0260] The processor is used to: obtain double-boundary memory write operation parameters by dynamically expanding the memory write operation functions of the kernel program, wherein the memory write operation parameters include the destination memory address and the length of the data to be written to memory;

[0261] The system determines whether the length of the data written to memory exceeds the pre-allocated memory size and whether the destination memory address intrudes into the memory sentinel value placement area.

[0262] If the length of data written to memory exceeds the pre-allocated memory size or the destination memory address intrudes into the memory sentinel value placement area, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0263] The processor is configured to: respond to a memory write data length less than or equal to the pre-allocated memory size and the destination memory address not intruding into the memory sentinel value placement area, and then continue writing to the requested memory through a memory request.

[0264] The processor is used to: create a candidate set for the memory cache pool;

[0265] Create a candidate set for the memory cache pool, including:

[0266] The first cache pool is determined based on the memory allocation size;

[0267] Obtain the memory allocation count from the hash table of the vulnerability object's allocation function characteristics;

[0268] If the number of memory allocations exceeds the first threshold, the cache for which memory was requested is determined to be the second cache pool;

[0269] If the number of memory allocations is less than or equal to the first threshold, the cache for which the memory was requested is determined to be the third cache pool;

[0270] Generate a candidate set of cache pools based on the first cache pool, the second cache pool, and the third cache pool;

[0271] The target cache pool is determined from the candidate cache pool set, and memory requests are reallocated through the target cache pool.

[0272] Specifically, such as Figure 4 As shown, the function start / stop module of this application is used to help administrators control the defense function. It not only supports manual start / stop operations, but also configures the automatic startup (WantedBy=multi-user.target) and failure restart (Restart=on-failure) mechanism based on the systemd service framework; it can prevent the function from failing after system restart or abnormal exit of the defense process, and ensure the continuity of kernel heap overflow defense.

[0273] The kfunc proxy injection module is used for the dynamic extension mechanism of kfunc in EBPF programs. Through BTF (BPFType Format) related macros (such as BTF_ID_FLAGS), bpf_proxy_kmalloc() and bpf_proxy_kfree() are registered as kernel-compliant functions, serving as proxy functions for the kernel's native heap memory allocation function kmalloc() and heap memory deallocation function kfree(), respectively. In this way, EBPF programs can indirectly call the kernel's native heap memory allocation function kmalloc() and heap memory deallocation function kfree() through the compliantly injected proxy functions without modifying the kernel source code. This allows for non-intrusive monitoring of kernel heap memory operations by indirectly calling the kernel memory management interface through these two proxy functions.

[0274] Data acquisition module: Employing the kprobe probe technology of the EBPF program, it monitors the calls to kernel heap memory allocation functions (such as kmalloc) and vulnerability object allocation functions in real time. Ultimately, it collects the starting address of the memory allocated, the size of the allocated memory, and the location where the sentinel value (Canary, a security mechanism used to detect buffer overflows) should be placed. For example, if the starting address of the allocated memory is 0xffffffffac1c4da0 and the size of the allocated memory is 56 bytes, then the location of the Canary is "0xffffffffac1c4da0 + 56 = 0xffffffffac1c4df6, and the size of the Canary value does not exceed 8 bytes".

[0275] In addition, to avoid lock contention caused by multiple CPUs accessing the same key simultaneously, a per-CPU hash table is used to store memory-related data and the location where the Canary value should be placed. For example, key data collected by monitoring heap memory allocation functions and vulnerability object allocation functions are stored in two hash tables of type BPF_MAP_TYPE_PERCPU_HASH: one is the memory allocation function hash table alloc_map (the key is the memory address, and the value is an alloc_meta structure, which is used to record the memory allocation size and the location where the Canary value should be placed), and the other is the vulnerability object allocation function hash table hole_map (the key is the process PID, and the value is a hole_meta structure, which is used to record the process PID, the stackid identifier of the vulnerability allocation point function call stack generated by bpf_get_stackid, and the count of memory allocations), providing data support for subsequent overflow detection and defense actions.

[0276] Real-time detection module: Monitors memory write operations and performs double boundary checks for overflow; uses the EBPF program's probe tool kprobe to hook key kernel memory write operation functions (such as memcpy(), copy_from_user()) to capture the core parameters of memory write operations in real time, including the destination memory address dest and the length of data to be written len; uses dest as an index to query the hash table alloc_map of the memory allocation function, obtains the information recorded in the alloc_meta structure, and then performs double boundary checks: first, it checks whether the write length len exceeds the actual size when the memory is requested; second, it checks whether the memory write range ((char*)dest+len) exceeds the memory block boundary and intrudes into the canary value storage area, thereby quickly identifying heap overflow risks.

[0277] Overflow Response Module: As the execution unit of the defense closed loop, it triggers multi-dimensional defense actions when an overflow risk is detected: the first step is to release the originally requested memory, thereby blocking the overflow propagation path; the second step is to execute the memory reallocation strategy of "limiting the cache range + random allocation".

[0278] The beneficial effects of the technical solutions provided in this application are:

[0279] This application can block privilege escalation and kernel crashes caused by memory heap overflow in real time, while solving the problems of memory fragmentation and defense lag, significantly improving the continuous assurance capability of critical business scenarios.

[0280] This application's technical solution achieves dynamic monitoring and proactive defense against heap overflow attacks without modifying the Linux system kernel source code. Through sentinel canary values ​​and double boundary checks, it enables real-time detection and blocking of heap overflows, completely preventing privilege escalation and system crashes. It reduces lock contention through a per-CPU hash table; controls memory fragmentation by dynamically defining the cache range, making it suitable for production environments; based on the kernel function call mechanism, it requires no kernel source code modification and supports Linux versions 5.8 and above; and it precisely locates vulnerable object allocation functions through processes and identifiers, enabling strict defense only for high-risk memory requests, avoiding indiscriminate interference with normal memory allocation, and further reducing system performance overhead.

[0281] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in the memory management method embodiment, the method including:

[0282] The processor obtains the kernel's native heap memory allocation and deallocation functions by dynamically extending the kernel program;

[0283] Obtain the vulnerability object allocation function;

[0284] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0285] Perform a write operation to memory;

[0286] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0287] Heap overflow detection for memory write operations is performed based on the comparison results;

[0288] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0289] like Figure 5 As shown, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the memory management method embodiments at runtime, the method including:

[0290] The processor obtains the kernel's native heap memory allocation and deallocation functions by dynamically extending the kernel program;

[0291] Obtain the vulnerability object allocation function;

[0292] By using probe tools that dynamically extend kernel programs, we can monitor kernel heap memory allocation functions and vulnerability object allocation functions, and collect memory pre-allocation data based on the monitoring results. The memory pre-allocation data includes one or more of the following: the starting address of the pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0293] Perform a write operation to memory;

[0294] The double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address.

[0295] Heap overflow detection for memory write operations is performed based on the comparison results;

[0296] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0297] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0298] Embodiments of this application also provide a computer program product, which includes a computer program. When executed by a processor, the computer program implements the steps in the memory management method embodiments, the method including:

[0299] The processor obtains the kernel's native heap memory allocation and deallocation functions by dynamically extending the kernel program;

[0300] Obtain the vulnerability object allocation function;

[0301] The kernel heap memory allocation function and the vulnerability object allocation function are monitored by a probe tool that dynamically extends the kernel program. Based on the monitoring results, memory pre-allocation data is collected. The memory pre-allocation data includes one or more of the following: the starting address of the memory pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0302] Perform a write operation to memory;

[0303] The double-boundary memory write operation parameters are compared with the pre-allocated memory data, wherein the double-boundary memory write operation parameters include the length of the memory write data and the destination memory address;

[0304] Heap overflow detection for memory write operations is performed based on the comparison results;

[0305] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0306] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps in the memory management method embodiments, the method including:

[0307] The processor obtains the kernel's native heap memory allocation and deallocation functions by dynamically extending the kernel program;

[0308] Obtain the vulnerability object allocation function;

[0309] The kernel heap memory allocation function and the vulnerability object allocation function are monitored by a probe tool that dynamically extends the kernel program. Based on the monitoring results, memory pre-allocation data is collected. The memory pre-allocation data includes one or more of the following: the starting address of the memory pre-allocated memory, the size of the memory space, and the location of the memory sentinel value.

[0310] Perform a write operation to memory;

[0311] The double-boundary memory write operation parameters are compared with the pre-allocated memory data, wherein the double-boundary memory write operation parameters include the length of the memory write data and the destination memory address;

[0312] Heap overflow detection for memory write operations is performed based on the comparison results;

[0313] If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm.

[0314] This application can block privilege escalation and kernel crashes caused by memory heap overflow in real time, while solving the problems of memory fragmentation and defense lag, significantly improving the continuous assurance capability of critical business scenarios.

[0315] This application's technical solution achieves dynamic monitoring and proactive defense against heap overflow attacks without modifying the Linux system kernel source code. Through sentinel canary values ​​and double boundary checks, it enables real-time detection and blocking of heap overflows, completely preventing privilege escalation and system crashes. It reduces lock contention through a per-CPU hash table; controls memory fragmentation by dynamically defining the cache range, making it suitable for production environments; based on the kernel function call mechanism, it requires no kernel source code modification and supports Linux versions 5.8 and above; and it precisely locates vulnerable object allocation functions through processes and identifiers, enabling strict defense only for high-risk memory requests, avoiding indiscriminate interference with normal memory allocation, and further reducing system performance overhead.

[0316] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0317] The foregoing has provided a detailed description of a memory management method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A memory management method, characterized in that, The method includes: Obtain kernel native heap memory allocation and deallocation functions by dynamically extending kernel programs; Obtain the vulnerability object allocation function; The kernel heap memory allocation function and the vulnerability object allocation function are monitored by the probe tool of the dynamically extended kernel program EBPF. Based on the monitoring results, memory pre-allocation data is collected. The memory pre-allocation data includes one or more of the following: the starting address of the memory pre-allocated memory, the size of the memory space, and the location of the memory sentinel value. A write operation is performed on memory, and the double-boundary memory write operation parameters are compared with the pre-allocated memory data. The double-boundary memory write operation parameters include the length of the data to be written to memory and the destination memory address. Heap overflow detection for memory write operations is performed based on the comparison results; If the heap overflow detection result for the memory write operation fails, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm. The method of reallocating memory requests using a dynamic cache pool algorithm includes: Create a candidate set for the memory cache pool; The candidate set for creating a memory cache pool includes: The first cache pool is determined based on the memory request size; Obtain the memory allocation count from the feature hash table of the allocation function of the vulnerability object; If the number of memory allocations exceeds a first threshold, the cache for the memory allocation is determined to be the second cache pool. If the number of memory allocations is less than or equal to a first threshold, then the cache for the memory request is determined to be the third cache pool; Generate a cache pool candidate set based on the first cache pool, the second cache pool, and the third cache pool; A target cache pool is determined from the candidate cache pool set, and memory requests are reallocated through the target cache pool.

2. The memory management method according to claim 1, characterized in that, Before obtaining the kernel's native heap memory allocation and deallocation functions through dynamically extended kernel programs, the following steps are included: Configure kernel heap overflow protection service; The configuration of the kernel heap overflow defense service includes: Configure the start / stop control method for the kernel heap overflow defense service through the service manager. The start / stop control method for the kernel heap overflow defense service includes one or more of the following: manual start / stop, fault restart, and automatic startup.

3. The memory management method according to claim 1, characterized in that, Before obtaining the kernel's native heap memory allocation and deallocation functions through dynamically extended kernel programs, the process also includes: The dynamically extended kernel program is initialized; The initialization of the dynamically extended kernel program includes: Define a hash table for memory allocation function metadata, set the key of the hash table to the pre-allocated memory address, and set the value of the hash table to a memory allocation function metadata structure. The memory allocation function metadata structure is used to record the size of the pre-allocated memory space and the location of the memory sentinel value. Define a feature hash table for vulnerability object allocation functions, set the key of the feature hash table to the process that allocates the vulnerability memory object, and set the value of the feature hash table to a feature structure of the vulnerability object allocation function. The feature structure of the vulnerability object allocation function is used to record the number of memory allocations, the process that allocates the vulnerability memory object, and the call stack information of the vulnerability object allocation function.

4. The memory management method according to claim 1, characterized in that, The method of obtaining kernel native heap memory allocation and deallocation functions through dynamically extended kernel programs includes: The proxy functions for the kernel native heap memory allocation function and heap memory deallocation function are determined through the kernel function call mechanism of the dynamically extended kernel program. The kernel native heap memory allocation function and heap memory deallocation function are obtained through the proxy functions of the kernel native heap memory allocation function and heap memory deallocation function, respectively.

5. The memory management method according to claim 1, characterized in that, The process involves using a probe tool that dynamically extends the kernel program to monitor the kernel heap memory allocation function and the vulnerable object allocation function, and collecting memory pre-allocation data based on the monitoring results, including: The probe tool of the dynamically extended kernel program is used to monitor the vulnerability object allocation function, obtain the vulnerability allocation point metadata based on the monitoring results of the vulnerability object allocation function, and store the vulnerability allocation point metadata in the vulnerability object allocation function feature hash table; The vulnerability allocation point metadata includes the number of memory allocations, the process that allocated the vulnerability memory object, and the stack identifier generated from the function call stack information of the vulnerability object allocation.

6. The memory management method according to claim 5, characterized in that, The step of obtaining vulnerability allocation point metadata based on the monitoring results of the vulnerability object allocation function and storing the vulnerability allocation point metadata in the vulnerability object allocation function feature hash table includes: The kernel heap memory allocation function is monitored using a probe tool that dynamically extends the kernel program; Determine whether the process and call stack information of the vulnerable memory object in the current memory allocation request are consistent with the process and call stack information of the vulnerable memory object in the feature hash table of the vulnerability object allocation function; If the process and call stack information of the vulnerable memory object allocated in the current memory request are consistent with the process and call stack information of the vulnerable memory object allocated in the feature hash table of the vulnerability object allocated, then the metadata of the memory allocation function is stored in the metadata hash table of the memory allocation function, wherein the metadata of the memory allocation function is memory pre-allocation data.

7. The memory management method according to claim 5, characterized in that, The step of comparing the double-boundary memory write operation parameters with the pre-allocated memory data, and detecting heap overflow of the memory write operation based on the comparison result; in response to the heap overflow detection result of the memory write operation failing, the original memory allocation is released through the heap memory release function, and the memory allocation is reallocated through the dynamic cache pool algorithm, including: The double-boundary memory write operation parameters are obtained through the memory write operation function of the dynamically extended kernel program, wherein the memory write operation parameters include the destination memory address and the length of the data to be written to memory. The system determines whether the length of the data written to memory is greater than the pre-allocated memory size and whether the destination memory address intrudes into the memory sentinel value placement area. In response to the memory write data length being greater than the pre-allocated memory size or the destination memory address intruding into the memory sentinel value placement area, the original memory request is released through the heap memory release function, and the memory request is reallocated through the dynamic cache pool algorithm; The method further includes: If the length of the data written to memory is less than or equal to the size of the pre-allocated memory and the destination memory address does not intrude into the memory sentinel value placement area, then the memory request will be used to continue writing to the requested memory.

8. The memory management method according to claim 6, characterized in that, After releasing the original memory allocation through the heap memory release function and reallocating the memory allocation using the dynamic cache pool algorithm, the process includes: Verify the process of releasing the original memory allocation; The verification of the original memory allocation release process includes: The metadata of the vulnerability object allocation function feature hash table and the memory allocation function metadata hash table is deleted through the heap memory release function; The step of deleting the metadata from the vulnerability object allocation function feature hash table and the memory allocation function metadata hash table through the heap memory release function includes: If the metadata corresponding to the original memory request exists in the metadata hash table of the memory allocation function, then the metadata corresponding to the original memory request is deleted from the metadata hash table of the memory allocation function. If the memory request being released belongs to the process that allocated the vulnerable memory object and the process that allocated the vulnerable memory object has terminated, then the metadata corresponding to the original memory request in the feature hash table of the vulnerability object's allocation function is deleted.

9. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer programs; A processor for implementing the steps of the memory management method as described in any one of claims 1 to 8 when executing the computer program.

Images