1. 問題描述：

Udp 高頻攻擊導致slab kmalloc-64 持續申請，導致內存不足。A7低版本內核無該問題，MA35/AM62在kernel6版本上也無該問題，此問題只出在A7 kernel6上。 問題環境（kernel6.6） iptables在不同環境下的版本相同

[root@evse ~]# uname -aLinux evse 6.6.90-gf2b2a1246566 #1 SMP PREEMPT Wed Jun 4 15:06:07 CST 2025armv7l GNU/Linux[root@evse ~]# cat /proc/cpuinfoprocessor : 0model name : ARMv7 Processor rev 5 (v7l)BogoMIPS : 64.00Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idivaidivt vfpd32 lpaeCPU implementer : 0x41CPU architecture: 7CPU variant : 0x0CPU part : 0xc07CPU revision : 5Hardware : Freescale i.MX6 Ultralite (Device Tree)Revision : 0000Serial : d9656bca271e39d4[root@evse ~]#

2. 測試命令

刪除規則與查看規則：

iptables -D INPUT 1iptables -L INPUT --line-numbers

兩條問題規則（-m connlimit )：

iptables -A INPUT -p udp -m connlimit --connlimit-above 60 --connlimit-mask 32 -m limit --limit2/min -j LOG --log-prefix "UDP Flood Limit Exceeded: " iptables -A INPUT -p udp -m connlimit --connlimit-above 60 --connlimit-mask 32 -j DROP

虛擬機對目標機使用不同間隔進行攻擊：

sudo hping3 --udp -s 6666 -p 443 --flood 192.168.88.206 kmalloc-64 持續增加sudo hping3 --udp -s 6666 -p 443 -i u2000 192.168.88.206 kmalloc-64 不持續增加sudo hping3 --udp -s 6666 -p 443 -i u200 192.168.88.206 kmalloc-64 不持續增加sudo hping3 --udp -s 6666 -p 443 -i u20 192.168.88.206 kmalloc-64 持續增加 ，刪除規則后，kmalloc-64恢復原來較低數值。若此時不刪除規則，并且停止-i u20 攻擊， kmalloc-64 會一直保持原高值不變，若此時再使用-i u200 進行攻擊，kmalloc-64 會在原來高值情況下慢慢減小，最終回到內存正常狀態。

通過如下命令可查看有問題時，可用內存下降， kmalloc-64 會持續增加

watch -n1 cat /proc/meminfo |grep "MemFree"watch -n1 "awk 'NR==1; NR>1 {print | \"sort -k2 -nr | head -n 11\"}' /proc/slabinfo"watch -n1 iptables -L -vn

3. kernel4.14.98 （無問題）

此內核無該類問題，規則生效，但內存不會增長。

注意：該環境iptables兩條udp規則和洪澇攻擊并不會導致內存泄露，但是產品線S83中的preconf會導致空閑內存越來越少。（因固件包過老，暫不查產品線的問題）

4. kernel6.6 （有問題）

4.1 kmalloc-64 內存異常

• 第一列: slab 緩存的名稱，
• 第二列（active_objs） :當前活躍的對象數量，
• 第三列（num_objs） :緩存中總對象數量（包括活躍和非活躍）,
• 第四列（objsize）:每個對象的大?。ㄗ止潱?
• 第五列（objperslab） :每個 slab 頁能存放的對象數量,
• 第六列（pagesperslab） :每個 slab 占用的內存頁數， 通常為 1。

tunables 部分可調參數（通常為 0，表示使用默認值）slabdata 部分 • 第一個值：活躍的 slab 頁數量。（因每個slab占用內存物理頁為1個，也可認為此值是該slab的個 數） • 第二個值：總 slab 頁數量。 • 第三個值：共享 slab 頁數量 總對象個數=slab組數每組對象 如 82176=128464 其中81887為當前活躍的對象

slab內存回收是以slab單個節點來回收，一個slab控制器包含多個obj，只有所有obj都非活躍狀態，slab節點才會被系統回收。所有只有釋放obj,后續才有slab內存回收。

當刪除規則，kmalloc-64立即回到原先正常大小?；蛘咴诓粍h除規則的環境下，此時再降速攻擊，kmalloc-64便會慢慢釋放，最終變回原先大?。?/span>

4.2 優化系統參數（縮減超時時間）：無效

echo 300 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_establishedecho 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberalecho 1 > /proc/sys/net/netfilter/nf_conntrack_generic_timeoutecho 5 > /proc/sys/net/netfilter/nf_conntrack_udp_timeoutecho 1 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout

4.3 內核調整：有效

CONFIG_HZ_1000 CONFIG_HZ=1000 ----- 在答疑Q2中詳細說明原因CONNCOUNT_GC_MAX_NODES 從8設置成64 ----- 增加單次釋放節點的個數，查找資料64適合高并發的攻擊環境if ((u32)jiffies == list->last_gc) 改成 if ((u32)jiffies == READ_ONCE(list->last_gc)) -------以保讀取最新值，

禁止編譯器優化為重復讀取或重排指令

單核設備應配置CONFIG_NR_CPUS=1 ，并關閉CONFIG_SMP 以匹配硬件 -----a7所有配置都應做此調整

4.4 代碼追蹤

iptables -A INPUT -p udp -m connlimit --connlimit-above 60 --connlimit-mask 32 -j DROP 

規則會 觸發 connlimit_mt_check -> nf_conncount_init insert_tree

iptables -D INPUT 1刪除上述規則，會觸發connlimit_mt_destroy -> nf_conncount_destroy ->destroy_tree

使用sudo hping3 --udp -s 6666 -p 443 -i u2000000 192.168.88.206進行攻擊： 因間隔為2秒，非高頻攻擊狀態，無包被DROP， 此時無__nf_conncount_add 和conn_free 函數的 執行。

4.4.1 節點創建：

__nf_conncount_add -> kmem_cache_alloc(conncount_conn_cachep, GFP_ATOMIC) （此函數便是分配slab的緩存對象）

4.4.2 節點釋放：

find_or_evict 用來查找過期節點，并將其釋放。

1. 1. 在添加節點時釋放

__nf_conncount_add -> find_or_evict -> conn_free ->kmem_cache_free(conncount_conn_cachep, conn) 

（此函數便是釋放slab的緩存對象）

1. 1. 在其他處釋放

connlimit_mt ->nf_conncount_count ->count_tree -> nf_conncount_gc_list -> find_or_evict   -> insert_tree -> nf_conncount_gc_list -> find_or_evict        - > schedule_gc_worker -> schedule_gc_worker -> schedule_work

schedule_work 觸發工作隊列去執行 tree_gc_worker -> nf_conncount_gc_list -> find_or_evict

connlimit_mt 主要用于限制單個 IP 的連接數

nf_conncount_count 統計當前鍵值對應的連接數

4.5 攻擊測試

4.5.1 使用sudo hping3 --udp -s 6666 -p 443 -i u200000 192.168.88.206 進行

攻擊6秒左右：

Welcome to EVSEevse login: [ 106.484184] **[connlimit_mt_check:95]**[ 106.488585] **[nf_conncount_init:539]**[ 110.288686] **[insert_tree:366]**Welcome to EVSEevse login:Welcome to EVSEevse login:Welcome to EVSEevse login:Welcome to EVSEevse login: [ 132.168009] **[insert_tree:366]**[ 132.377315] **[__nf_conncount_add:186]**[ 132.588389] **[__nf_conncount_add:186]**[ 132.792491] **[__nf_conncount_add:186]**[ 132.992824] **[__nf_conncount_add:186]**[ 133.196611] **[__nf_conncount_add:186]**[ 133.398087] **[__nf_conncount_add:186]**[ 133.602361] **[__nf_conncount_add:186]**[ 133.810499] **[__nf_conncount_add:186]**[ 134.013903] **[__nf_conncount_add:186]**[ 134.215048] **[__nf_conncount_add:186]**[ 134.420325] **[__nf_conncount_add:186]**[ 134.625043] **[__nf_conncount_add:186]**[ 134.825720] **[__nf_conncount_add:186]**[ 135.028171] **[__nf_conncount_add:186]**[ 135.230085] **[__nf_conncount_add:186]**[ 135.430352] **[__nf_conncount_add:186]**[ 135.631057] **[__nf_conncount_add:186]**[ 135.835375] **[__nf_conncount_add:186]**[ 136.044689] **[__nf_conncount_add:186]**[ 136.249517] **[__nf_conncount_add:186]**[ 136.449621] **[__nf_conncount_add:186]**[ 136.652949] **[__nf_conncount_add:186]**

4.5.2 上一步前提下，過一段時間再使用sudo hping3 --udp -s 6666 -p 443 -i u200000 192.168.88.206 進行攻擊2秒左右，從打印可看到先釋放原先創建的節點：

[ 246.340577] **[conn_free:92]**[ 246.343988] **[conn_free:92]**[ 246.347228] **[conn_free:92]**[ 246.350448] **[conn_free:92]**[ 246.353663] **[conn_free:92]**[ 246.356968] **[conn_free:92]**[ 246.360190] **[conn_free:92]**[ 246.363408] **[conn_free:92]**[ 246.366622] **[conn_free:92]**[ 246.369831] **[__nf_conncount_add:186]**[ 246.544568] **[conn_free:92]**[ 246.547849] **[conn_free:92]**[ 246.551030] **[conn_free:92]**[ 246.554201] **[conn_free:92]**[ 246.557367] **[conn_free:92]**[ 246.560535] **[conn_free:92]**[ 246.563701] **[conn_free:92]**[ 246.566866] **[conn_free:92]**[ 246.570031] **[conn_free:92]**[ 246.573193] **[__nf_conncount_add:186]**[ 246.749883] **[conn_free:92]**[ 246.753196] **[conn_free:92]**[ 246.756645] **[conn_free:92]**[ 246.759876] **[conn_free:92]**[ 246.763095] **[conn_free:92]**[ 246.766407] **[__nf_conncount_add:186]**[ 246.961836] **[__nf_conncount_add:186]**[ 247.162273] **[__nf_conncount_add:186]**[ 247.362697] **[__nf_conncount_add:186]**[ 247.563052] **[__nf_conncount_add:186]**

4.5.3 斷電重啟后，使用sudo hping3 --udp -s 6666 -p 443 -i u200000 192.168.88.206 進行攻擊30秒左右

可以看到先連續創建前60個（200ms一幀，12秒正好60個），期間沒有conn_free，這是因為之前**-- connlimit-above 60** 參數的原因，可以看到后期每增加一個節點，便會釋放一個節點。內核的nf_conncount 模塊會優先釋放最早創建的連接 （FIFO策略）。

Welcome to EVSEevse login: [ 6588.953200] **[connlimit_mt_check:95]**[ 6588.964224] **[nf_conncount_init:539]**Welcome to EVSEevse login: [ 6623.889501] **[insert_tree:366]**[ 6624.092922] **[__nf_conncount_add:186]**[ 6624.293990] **[__nf_conncount_add:186]**[ 6624.496559] **[__nf_conncount_add:186]**[ 6624.704156] **[__nf_conncount_add:186]**[ 6624.905262] **[__nf_conncount_add:186]**[ 6625.117401] **[__nf_conncount_add:186]**[ 6625.332664] **[__nf_conncount_add:186]**[ 6625.534785] **[__nf_conncount_add:186]**[ 6625.735500] **[__nf_conncount_add:186]**[ 6625.936776] **[__nf_conncount_add:186]**[ 6626.142550] **[__nf_conncount_add:186]**[ 6626.464095] **[__nf_conncount_add:186]**[ 6626.672264] **[__nf_conncount_add:186]**[ 6626.876006] **[__nf_conncount_add:186]**[ 6627.080153] **[__nf_conncount_add:186]**[ 6627.280599] **[__nf_conncount_add:186]**[ 6627.485330] **[__nf_conncount_add:186]**[ 6627.688502] **[__nf_conncount_add:186]**[ 6627.890940] **[__nf_conncount_add:186]**[ 6628.093806] **[__nf_conncount_add:186]**[ 6628.313874] **[__nf_conncount_add:186]**[ 6628.515991] **[__nf_conncount_add:186]**[ 6628.720403] **[__nf_conncount_add:186]**[ 6628.924391] **[__nf_conncount_add:186]**[ 6629.126770] **[__nf_conncount_add:186]**[ 6629.330207] **[__nf_conncount_add:186]**[ 6629.533838] **[__nf_conncount_add:186]**[ 6629.734090] **[__nf_conncount_add:186]**[ 6629.934281] **[__nf_conncount_add:186]**[ 6630.135378] **[__nf_conncount_add:186]**[ 6630.335804] **[__nf_conncount_add:186]**[ 6630.537249] **[__nf_conncount_add:186]**[ 6630.740110] **[__nf_conncount_add:186]**[ 6630.942853] **[__nf_conncount_add:186]**[ 6631.143030] **[__nf_conncount_add:186]**[ 6631.346782] **[__nf_conncount_add:186]**[ 6631.547754] **[__nf_conncount_add:186]**[ 6631.747852] **[__nf_conncount_add:186]**[ 6631.948470] **[__nf_conncount_add:186]**[ 6632.152779] **[__nf_conncount_add:186]**[ 6632.364964] **[__nf_conncount_add:186]**[ 6632.576077] **[__nf_conncount_add:186]**[ 6632.796017] **[__nf_conncount_add:186]**[ 6632.997078] **[__nf_conncount_add:186]**[ 6633.203338] **[__nf_conncount_add:186]**[ 6633.406403] **[__nf_conncount_add:186]**[ 6633.607636] **[__nf_conncount_add:186]**[ 6633.812599] **[__nf_conncount_add:186]**[ 6634.024786] **[__nf_conncount_add:186]**[ 6634.225224] **[__nf_conncount_add:186]**[ 6634.427251] **[__nf_conncount_add:186]**[ 6634.642583] **[__nf_conncount_add:186]**[ 6634.842924] **[__nf_conncount_add:186]**[ 6635.042996] **[__nf_conncount_add:186]**[ 6635.243920] **[__nf_conncount_add:186]**[ 6635.461265] **[__nf_conncount_add:186]**[ 6635.670469] **[__nf_conncount_add:186]**[ 6635.871427] **[__nf_conncount_add:186]**[ 6636.079939] **[__nf_conncount_add:186]**[ 6636.280148] **[__nf_conncount_add:186]**[ 6636.481285] **[conn_free:92]**[ 6636.484515] **[__nf_conncount_add:186]**[ 6636.682712] **[conn_free:92]**[ 6636.686019] **[__nf_conncount_add:186]**[ 6636.883322] **[conn_free:92]**[ 6636.886627] **[__nf_conncount_add:186]**[ 6637.093071] **[conn_free:92]**[ 6637.096471] **[__nf_conncount_add:186]**[ 6637.308856] **[conn_free:92]**[ 6637.312146] **[__nf_conncount_add:186]**[ 6637.509549] **[conn_free:92]**[ 6637.512862] **[__nf_conncount_add:186]**[ 6637.715686] **[conn_free:92]**[ 6637.718980] **[__nf_conncount_add:186]**[ 6637.918133] **[conn_free:92]**[ 6637.921462] **[__nf_conncount_add:186]**[ 6638.122847] **[conn_free:92]**[ 6638.126249] **[__nf_conncount_add:186]**[ 6638.346137] **[conn_free:92]** [ 6638.349367] **[__nf_conncount_add:186]**[ 6638.562855] **[conn_free:92]**[ 6638.566084] **[__nf_conncount_add:186]**

4.5.4 若使用sudo hping3 --udp -s 6666 -p 443 -i u20 192.168.88.206 進行高頻攻擊

我們可以看到創建節點速度要明顯快于釋放。Kernel 6.6對連接跟蹤模塊進行了重構，新增了更嚴格的連接狀態檢查機制，導致處理每個連接需要更多CPU周期。

創建快是因為僅需分配內存，而釋放需完成哈希表操作、狀態清理等耗時步驟。

[10060.558838] **[__nf_conncount_add:186]**[10060.558854] **[__nf_conncount_add:186]**[10060.558873] **[__nf_conncount_add:186]**[10060.558889] **[__nf_conncount_add:186]**[10060.558907] **[__nf_conncount_add:186]**[10060.559033] **[__nf_conncount_add:186]**[10060.559058] **[__nf_conncount_add:186]**[10060.559081] **[__nf_conncount_add:186]**[10060.559098] **[__nf_conncount_add:186]**[10060.559116] **[__nf_conncount_add:186]**[10060.559134] **[__nf_conncount_add:186]**[10060.559152] **[__nf_conncount_add:186]**[10060.559170] **[__nf_conncount_add:186]**[10060.559294] **[__nf_conncount_add:186]**[10060.559318] **[__nf_conncount_add:186]**[10060.559342] **[__nf_conncount_add:186]**[10060.559360] **[__nf_conncount_add:186]**[10060.559380] **[__nf_conncount_add:186]**[10060.559399] **[__nf_conncount_add:186]**[10060.559417] **[__nf_conncount_add:186]**[10060.559436] **[__nf_conncount_add:186]**[10060.559562] **[__nf_conncount_add:186]**[10060.559587] **[__nf_conncount_add:186]**[10060.559607] **[__nf_conncount_add:186]**[10060.559624] **[__nf_conncount_add:186]**[10060.559642] **[__nf_conncount_add:186]**[10060.559660] **[__nf_conncount_add:186]**[10060.559678] **[__nf_conncount_add:186]**[10060.559696] **[__nf_conncount_add:186]**[10060.559833] **[__nf_conncount_add:186]**[10060.559861] **[__nf_conncount_add:186]**[10060.559880] **[__nf_conncount_add:186]**[10060.559899] **[__nf_conncount_add:186]**[10060.559918] **[__nf_conncount_add:186]**[10060.559936] **[__nf_conncount_add:186]**[10060.559954] **[__nf_conncount_add:186]**[10060.559972] **[__nf_conncount_add:186]**[10060.560100] **[__nf_conncount_add:186]**[10060.560125] **[__nf_conncount_add:186]**[10060.560147] **[__nf_conncount_add:186]**[10060.560164] **[__nf_conncount_add:186]**[10060.560182] **[__nf_conncount_add:186]**[10060.560201] **[__nf_conncount_add:186]**[10060.560219] **[__nf_conncount_add:186]**[10060.560239] **[__nf_conncount_add:186]**[10060.560371] **[__nf_conncount_add:186]**[10060.560394] **[__nf_conncount_add:186]**[10060.560413] **[__nf_conncount_add:186]**[10060.560429] **[__nf_conncount_add:186]**[10060.560445] **[__nf_conncount_add:186]**[10060.560482] **[__nf_conncount_add:186]**[10060.560500] **[__nf_conncount_add:186]**[10060.560518] **[__nf_conncount_add:186]**[10060.560646] **[__nf_conncount_add:186]**[10060.560671] **[__nf_conncount_add:186]**[10060.560688] **[__nf_conncount_add:186]**[10060.560705] **[__nf_conncount_add:186]**[10060.560842] **[conn_free:92]**[10060.560870] **[conn_free:92]**[10060.560883] **[conn_free:92]**[10060.560895] **[conn_free:92]**[10060.560906] **[conn_free:92]**[10060.560917] **[conn_free:92]**[10060.560929] **[conn_free:92]**[10060.560940] **[conn_free:92]**[10060.560952] **[conn_free:92]**[10060.560961] **[__nf_conncount_add:186]**[10060.560982] **[__nf_conncount_add:186]**[10060.561001] **[__nf_conncount_add:186]**[10060.561018] **[__nf_conncount_add:186]**[10060.561171] **[__nf_conncount_add:186]**[10060.561201] **[__nf_conncount_add:186]**[10060.561222] **[__nf_conncount_add:186]**[10060.561240] **[__nf_conncount_add:186]**[10060.561257] **[__nf_conncount_add:186]**[10060.561274] **[__nf_conncount_add:186]**[10060.561290] **[__nf_conncount_add:186]**[10060.561307] **[__nf_conncount_add:186]**[10060.561439] **[__nf_conncount_add:186]** [10060.561463] **[__nf_conncount_add:186]**[10060.561480] **[__nf_conncount_add:186]**[10060.561497] **[__nf_conncount_add:186]**[10060.561513] **[__nf_conncount_add:186]**[10060.561531] **[__nf_conncount_add:186]**[10060.561547] **[__nf_conncount_add:186]**[10060.561563] **[__nf_conncount_add:186]**[10060.561688] **[__nf_conncount_add:186]**[10060 561712] **[ f t dd:186]**

5 答疑

Q1: 從下面的代碼可以看到slab描述符的名稱應為nf_conncount_tuple，為何在proc/slabinfo中沒有？而出現增長的slab名稱確是malloc-64？

conncount_conn_cachep = kmem_cache_create("nf_conncount_tuple",sizeof(struct nf_conncount_tuple),0, 0, NULL);

slab描述符nf_conncount_tuple未在/proc/slabinfo顯示，因為對象尺寸與通用緩存匹配且未強制獨 立分配，內核會復用 malloc-64 緩存，所以在高頻攻擊下是malloc-64持續增加。

Q2: 為何Udp 高頻攻擊導致slab kmalloc-64 持續申請，導致內存不足？

高頻攻擊，有一個新連接便生成一個節點（add_new_node），就會申請一個slab對象（kmem_cache_alloc） 。 其中find_or_evict函數是用來釋放無效過期節點，注意if ((u32)jiffies == READ_ONCE(list->last_gc))的判斷邏輯，A7原CONFIG_HZ=100，也就是一個jiffies的單位就是10ms,當在這10ms時間內，這個函數直接到add_new_node出申請對象，而調過了釋放無效過期的邏輯。當高頻下（比如u20)，10ms內就有500個節點要連續申請。

在下一個10ms才會到find_or_evict的釋放邏輯，這樣內存申請過于密集。

find_or_evict的釋放邏輯還有注意點，每次它只釋放9個節點，當釋放完9個后，find_or_evict函數就返回。

這樣就可知道高頻攻擊下，因節點在短時間創建過多節點，而一次釋放最多9個，隨著時間的積累，內存會逐漸被kmalloc-64所消耗。

所以kernel6需做如下調整：CONFIG_HZ_1000 CONFIG_HZ=1000 CONNCOUNT_GC_MAX_NODES從8設置成64（64值適合高并發環境）。 （后期其他平臺用非rt內核kernel6，也需關注此處）

static int __nf_conncount_add(struct net *net,struct nf_conncount_list *list,const struct nf_conntrack_tuple *tuple,const struct nf_conntrack_zone *zone){ const struct nf_conntrack_tuple_hash *found; struct nf_conncount_tuple *conn, *conn_n; struct nf_conn *found_ct; unsigned int collect = 0; if ((u32)jiffies == READ_ONCE(list->last_gc))  goto add_new_node;  /* check the saved connections */  list_for_each_entry_safe(conn, conn_n, &list->head, node) {   if (collect > CONNCOUNT_GC_MAX_NODES)    break;   found = find_or_evict(net, list, conn);   if (IS_ERR(found)) {    /* Not found, but might be about to be confirmed */    if (PTR_ERR(found) == -EAGAIN) {     if (nf_ct_tuple_equal(&conn->tuple, tuple) &&     nf_ct_zone_id(&conn->zone, conn->zone.dir)     ==     nf_ct_zone_id(zone, zone->dir))    return 0; /* already exists */   } else {    collect++;   }  continue;  }  found_ct = nf_ct_tuplehash_to_ctrack(found);    if (nf_ct_tuple_equal(&conn->tuple, tuple) &&  nf_ct_zone_equal(found_ct, zone, zone->dir)) {   /*   * We should not see tuples twice unless someone hooks   * this into a table without "-p tcp --syn".   *   * Attempt to avoid a re-add in this case.   */   nf_ct_put(found_ct);   return 0;  } else if (already_closed(found_ct)) {   /*      * we do not care about connections which are   * closed already -> ditch it   */   nf_ct_put(found_ct);   conn_free(list, conn);   collect++;   continue;  }  nf_ct_put(found_ct); } add_new_node: if (WARN_ON_ONCE(list->count > INT_MAX))  return -EOVERFLOW; conn = kmem_cache_alloc(conncount_conn_cachep, GFP_ATOMIC); if (conn == NULL)  return -ENOMEM; conn->tuple = *tuple; conn->zone = *zone; conn->cpu = raw_smp_processor_id(); conn->jiffies32 = (u32)jiffies; list_add_tail(&conn->node, &list->head); list->count++; list->last_gc = (u32)jiffies; return 0;}

Q3：刪除規則后，kmalloc-64恢復原來較低數值？

iptables -D INPUT 1刪除規則，會觸發connlimit_mt_destroy -> nf_conncount_destroy ->destroy_tree -> kmem_cache_free ,便會把所用的slab對象全部釋放，所以kmalloc-64恢復原來較低 數值。

Q4：若此時不刪除規則，暫停攻擊， kmalloc-64 會一直保持原高值不變？

find_or_evict函數是用來釋放無效過期節點，雖然find_or_evict除了在我們介紹的 __nf_conncount_add函數里被調用，還會在其他幾個函數中被調用。

但是通過日志追蹤，實際find_or_evict只在__nf_conncount_add中執行。那么只有新節點過來，才會進入find_or_evict函數來釋放內存，所以暫停攻擊，kmalloc-64 就會一直保持原高值不變。

Q5：若此時再使用低頻進行攻擊， kmalloc-64 會在原來高值情況下慢慢減小，最終回到內存正常狀態？

當低頻攻擊時，__nf_conncount_add的在10ms內直接add_new_node就會少，同時find_or_evict函數一次最多可以釋放9個對象。這樣釋放節點數快于新節點的創建，所以kmalloc-64 會在原來高值情況下慢慢減小，最終會回到內存正常狀態。

Q6：find_or_evict會在多個函數被調用，為何實際只在__nf_conncount_add中執行？如果其他函數也會調用，這樣釋放節點就加快了，也可以避免該問題。

之前過分析的代碼：

connlimit_mt ->nf_conncount_count ->count_tree -> nf_conncount_gc_list -> find_or_evict -> insert_tree -> nf_conncount_gc_list -> find_or_evict  - > schedule_gc_worker -> schedule_gc_worker -> schedule_work

schedule_work 觸發工作隊列去執行tree_gc_worker -> nf_conncount_gc_list -> find_or_evict

首先對Q4的補充： connlimit_mt 和 __nf_conncount_add 均包含節點釋放邏輯，但兩者的觸發條件均依賴數據包的主動進入。 當高頻攻擊停止且無新數據包進入時，由于缺乏觸發條件，已分配的 kmalloc-64 內存（存儲連接計數節點）將無法釋放，導致內存占用維持高位。

static unsigned intcount_tree(struct net *net,struct nf_conncount_data *data,const u32 *key,const struct nf_conntrack_tuple *tuple,const struct nf_conntrack_zone *zone){ struct rb_root *root; struct rb_node *parent; struct nf_conncount_rb *rbconn; unsigned int hash; printk("**[%s:%d]** \n", __func__, __LINE__); hash = jhash2(key, data->keylen, conncount_rnd) % CONNCOUNT_SLOTS; root = &data->root[hash]; parent = rcu_dereference_raw(root->rb_node); while (parent) {  int diff;  rbconn = rb_entry(parent, struct nf_conncount_rb, node);  diff = key_diff(key, rbconn->key, data->keylen);  if (diff < 0) {   parent = rcu_dereference_raw(parent->rb_left);  } else if (diff > 0) {   parent = rcu_dereference_raw(parent->rb_right);  } else {   int ret;   printk("**[%s:%d]** \n", __func__, __LINE__);   if (!tuple) {    printk("**[%s:%d]** \n", __func__, __LINE__);    nf_conncount_gc_list(net, &rbconn->list);    return rbconn->list.count;   }   spin_lock_bh(&rbconn->list.list_lock);   /* Node might be about to be free'd.   * We need to defer to insert_tree() in this case.   */   if (rbconn->list.count == 0) {    spin_unlock_bh(&rbconn->list.list_lock);    break;   }   /* same source network -> be counted! */   ret = __nf_conncount_add(net, &rbconn->list, tuple,   zone);   spin_unlock_bh(&rbconn->list.list_lock);   if (ret)    return 0; /* hotdrop */   else    return rbconn->list.count;   } } printk("**[%s:%d]** \n", __func__, __LINE__); if (!tuple)  return 0; printk("**[%s:%d]** \n", __func__, __LINE__); return insert_tree(net, data, root, hash, key, tuple, zone);}

count_tree 為何沒進入上述釋放節點的邏輯：

• 因調用時始終傳入有效的 tuple 參數，跳過了直接調用 nf_conncount_gc_list 的路徑。
• 進入__nf_conncount_add邏輯后，直接返回，不再進入 insert_tree 函數調用，后續的釋放節點都走不到。