從一個跨二十年的glibc bug說起

周榮華發表於2021-09-08

1. 緣起

這幾天調gcc 7.5.0 +glibc 2.23的交叉編譯工具鏈，由於gcc 7.5.0的預設開啟Werr，偶然發現了glibc一個隱藏了二十年的世紀大bug。

這個bug在glibc 2.0版本剛開始就引入了，但直到2.25版本才最終解決，即使按glibc-2.0.1.bin.alpha-linux.tar.gz 版本的釋出時間（04-Feb-1997）到glibc-2.25.tar.bz2 的釋出時間（05-Feb-2017），也持續了20年加一天。

用gcc 7.5編譯的時候如果使能-Wall -Werror這2個選項（-Wall 英文說明是Enable most warning messages，表示使能大多數告警上報；-Werror表示所有告警都當錯誤來上報，不可忽略），會報下面的錯誤：

nss_nisplus/nisplus-alias.c: In function '_nss_nisplus_getaliasbyname_r':
nss_nisplus/nisplus-alias.c:300:12: error: argument 1 null where non-null expected [-Werror=nonnull]
   char buf[strlen (name) + 9 + tablename_len];
            ^~~~~~~~~~~~~
In file included from ../include/string.h:54:0,
                 from ../sysdeps/generic/hp-timing-common.h:40,
                 from ../sysdeps/x86_64/hp-timing.h:38,
                 from ../include/libc-internal.h:7,
                 from ../sysdeps/x86_64/nptl/tls.h:29,
                 from ../sysdeps/x86_64/atomic-machine.h:20,
                 from ../include/atomic.h:50,
                 from nss_nisplus/nisplus-alias.c:19:
../string/string.h:394:15: note: in a call to function 'strlen' declared here
 extern size_t strlen (const char *__s)
               ^~~~~~
nss_nisplus/nisplus-alias.c:303:39: error: '%s' directive argument is null [-Werror=format-truncation=]
   snprintf (buf, sizeof (buf), "[name=%s],%s", name, tablename_val);
                                       ^~
cc1: all warnings being treated as errors

 

如果不使能-Werror，編譯器最多會上報告警，程式還是能正常編譯通過。上面2個告警分別對strlen的入參和snprintf的字串格式化引數做了非空檢查，根據程式碼邏輯判斷，兩處程式碼如果執行到，呼叫的入參確實都必然是空指標。

 原始碼如下： 

276 enum nss_status
277 _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
278                 char *buffer, size_t buflen, int *errnop)
279 {
280   int parse_res;
281  
282   if (tablename_val == NULL)
283     {
284       __libc_lock_lock (lock);
285  
286       enum nss_status status = _nss_create_tablename (errnop);
287  
288       __libc_lock_unlock (lock);
289  
290       if (status != NSS_STATUS_SUCCESS)
291     return status;
292     }
293  
294   if (name != NULL)
295     {
296       *errnop = EINVAL;
297       return NSS_STATUS_UNAVAIL;
298     }
299  
300   char buf[strlen (name) + 9 + tablename_len];
301   int olderr = errno;
302  
303   snprintf (buf, sizeof (buf), "[name=%s],%s", name, tablename_val);
304  
305   nis_result *result = nis_list (buf, FOLLOW_PATH | FOLLOW_LINKS, NULL, NULL);

  

可以看出300行對應的strlen函式的入參要求非空，但由於294行做了一個非空的判斷並返回，也就是說如果294行的if判斷為非，那說明name指標必然為空，這時strlen來獲取字串長度就會異常。

具體會怎麼異常？我們可以寫個簡單的例子：

1 #include <stdio.h>
2 #include <string.h>
3 int main()
4 {
5     printf("%d", strlen(NULL));
6     return 0;
7 }

預設不帶任何引數的情況下，gcc會上報告警，但仍然可以編譯通過，執行後會出現Segmentation fault：

 1 gcc  test1.c
 2 test1.c: In function 'main':
 3 test1.c:5:5: warning: null argument where non-null required (argument 1) [-Wnonnull]
 4      printf("%d", strlen(NULL));
 5      ^
 6 test1.c:5:12: warning: format '%d' expects argument of type 'int', but argument 2 has type 'size_t {aka long unsigned int}' [-Wformat=]
 7      printf("%d", strlen(NULL));
 8             ^
 9 
10 ./a.out
11 Segmentation fault

編譯如果加上-Wall -Werror選項會直接報error編譯失敗：

1 gcc -Wall -Werror test1.c
2 test1.c: In function 'main':
3 test1.c:5:5: error: null argument where non-null required (argument 1) [-Werror=nonnull]
4      printf("%d", strlen(NULL));
5      ^
6 test1.c:5:12: error: format '%d' expects argument of type 'int', but argument 2 has type 'size_t {aka long unsigned int}' [-Werror=format=]
7      printf("%d", strlen(NULL));
8             ^
9 cc1: all warnings being treated as errors

問題的直接原因還是因為libc庫裡面的strlen沒有做空指標保護，直接訪問入參對應的記憶體了，所以實際上就會出現空指標訪問，程式異常退出。

同樣的303行的snprintf也要求%s對應的引數不能是空指標，否則也會出現Segmentation fault。

 

從上面的分析可以看出，有一些warning實際上本身就是錯誤，應該作為error來處理，在glibc的漫長進化過程中，有很多執行路徑可能真的沒走到（如果沒有100%覆蓋率的單元測試，也沒有完善的程式碼review機制，可能永遠也沒人會發現），或者確實不影響功能的正常釋出。但這些告警指向的程式碼，一旦走到就會出現致命錯誤。

最終glibc修正程式碼其實也很簡單，就是將294行的“if (name != NULL)”修改成了“if (name == NULL)”，一個運算子用反了。

很多影響非常大的bug，定位之後的實際修改都是簡單的一兩行程式碼的事情，但問題的關鍵是要發現bug並定位bug，並且在bug修正之後的波及測試工作。

這個bug之所有能持續20年沒人發現，只能說明glibc中應該還有很多程式碼在實際場景中沒有用到。

2. 編譯器的進化

 

下面這個表格給出了不同clang或者gcc版本新增的程式碼靜態檢查的告警計數，為了顯得簡潔一點，clang7或者更老的clang的所有告警做了一下彙總，gcc 4或者更老的gcc版本的所有告警也做了一下彙總，從中可以看出每次大版本升級，編譯器團隊都給開發團隊提供了一些新的工具能更多的發現自己程式碼bug的神器。

下面彙總的1204個告警中，有119個告警是clang和gcc都提供的，其他966個告警至少從名稱上看是gcc或者clang特有的。其中clang（以clang 12來算）特有的告警檢查項有803個，gcc（以gcc 9來算）有178個，單從這個指標看clang在靜態檢查方面是遠勝於gcc的，"2012 ACM Software System Award"大獎實至名歸。

不過clang本身是為了支撐llvm的，所以很多與llvm不相關的功能都是直接呼叫的gcc的庫介面，可以認為clang是站在gcc的巨人肩膀上來發布的自己的產品。

當前各個公司都引入了很多靜態檢查的工具來完善程式碼質量，但第一步還是要把靜態檢查工具的老祖宗，也就是編譯器，自帶的靜態檢查功能用足用好，再考慮消除其他靜態檢查工具的問題比較靠譜。走好這一步，引入clang非常必要。

first introduced compiler version

Count of new warning options
clang7 or older 584
clang8 12
clang9 223
clang10 55
clang11 33
clang12 15
gcc 4 or older 172
gcc 5 26
gcc 6 24
gcc 7 35
gcc 8 16
gcc 9 24
Grand Total 1204

 

相關文章