是否有任何可以捕獲此內存泄漏的靜態代碼分析器？

這樣的漏洞看起來太瑣碎了，我認爲靜態代碼分析工具應該能夠找到它們。是否有任何可以捕獲此內存泄漏的靜態代碼分析器？

Ex1: 
void foo(void) { 
    u32 *ptr = kmalloc(512, GFP_KERNEL); 
    ptr = (u32 *)0xffffffff; 
    kfree(ptr); 
}

我知道Coverity可以如下找到泄漏，但不知道上面的一個：任何人都可以請讓我知道這是否會在任何Coverity或工具，如Sparse獲得被檢測的？

Ex2: 
void foo(void) { 
    kmalloc(512, GFP_KERNEL); 
} 

Ex3: 
void foo(void) { 
    void * ptr = kmalloc(512, GFP_KERNEL); 

    if (true) 
     return; 

    kfree(ptr) 
}

來源

2015-02-10 Amit Sharma

你的例子很簡單。有兩個大頭釘。 Coverity和其他人試圖動態確定一個函數的功能。其他一些工具（如Sparse，splint等）需要註釋來捕獲額外的含義（超出語言範圍）。可以編寫[** Coccinelle **]（http://coccinelle.lip6.fr/）來檢測規則。這些工具可能具有內置的意義。 [gcc __attribute（）]（https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html），例如* format *，* malloc *，* nonnull *可能是或者是* annotations *的示例。 – 2015-02-10 19:16:09

內核中還有一個泄漏檢測器，它會給出分配調用者的回溯;作爲實際在內核空間工作的'Valgrind'的一個例子。上述任何工具*都可能*可能檢測到錯誤。有時很難解析代碼;特別是內聯彙編程序。 – 2015-02-10 19:18:00

你能否請解釋一下，Covery/Sparse如何檢測這個內存泄漏？我對「稀疏」知道一點，它可以警告我們以下消息： 'u32 * ptr = kmalloc（512，GFP_KERNEL）; '它會報告'不正確的類型分配警告'。但是對於這個'ptr =（u32 *）0xffffffff;'不會報告任何警告，因爲類型轉換會消除警告。那麼'Sparse'如何檢測這個內存泄漏？如果我錯了，請糾正我。 – 2015-02-11 06:17:47

-2

Valgrind可用於檢測在練習1提到的存儲器泄漏。

e.g. 
#include<stdio.h> 
void foo(void) { 
    int *ptr = (int *)malloc(512); 
    ptr = (int *)0xffffffff; 
    free(ptr); 
} 
int main(){ 
     foo(); 
     return 1; 
} 

Valigrind Output: 

[[email protected] /tmp]# valgrind --tool=memcheck --leak-check=full ./Ex1 
==23780== Memcheck, a memory error detector 
==23780== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. 
==23780== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info 
==23780== Command: ./Ex1 
==23780== 
==23780== Invalid free()/delete/delete[] 
==23780== at 0x4A05A31: free (vg_replace_malloc.c:325) 
==23780== by 0x400509: foo (in /tmp/Ex1) 
==23780== by 0x400514: main (in /tmp/Ex1) 
==23780== Address 0xffffffff is not stack'd, malloc'd or (recently) free'd 
==23780== 
==23780== 
==23780== HEAP SUMMARY: 
==23780==  in use at exit: 512 bytes in 1 blocks 
==23780== total heap usage: 1 allocs, 1 frees, 512 bytes allocated 
==23780== 
==23780== 512 bytes in 1 blocks are definitely lost in loss record 1 of 1 
==23780== at 0x4A05E1C: malloc (vg_replace_malloc.c:195) 
==23780== by 0x4004E9: foo (in /tmp/Ex1) 
==23780== by 0x400514: main (in /tmp/Ex1) 
==23780== 
==23780== LEAK SUMMARY: 
==23780== definitely lost: 512 bytes in 1 blocks 
==23780== indirectly lost: 0 bytes in 0 blocks 
==23780==  possibly lost: 0 bytes in 0 blocks 
==23780== still reachable: 0 bytes in 0 blocks 
==23780==   suppressed: 0 bytes in 0 blocks 
==23780== 
==23780== For counts of detected and suppressed errors, rerun with: -v 
==23780== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)

來源

2015-02-10 12:10:57 Shubhangi

但Valgrind不是**靜態**代碼分析器（他們只是「看」源代碼）。 Valgrind **執行代碼！ – 2015-02-10 12:18:53

我可以。!! Aplease的通知，因爲我已經提到'kmalloc（）'這是內核地址空間，我認爲'Valgrind'只能解決用戶空間內存泄漏。 – 2015-02-10 15:27:55

我不知道kmalloc（我沒有Linux系統與Coverity公司的許可來測試），但Coverity的檢測這種形式的泄漏與malloc容易。所以我懷疑kmalloc會給它帶來麻煩。

如果確實有問題，您可以隨時提供kmalloc函數的用戶模型，該函數只包含malloc函數，以便Coverity知道如何處理該函數。

來源

2015-02-16 17:47:17 Ben

是否有任何可以捕獲此內存泄漏的靜態代碼分析器？

回答

相關問題