LinuxカーネルでのLinuxバージョンのPVS-Studioのテスト

PVS-StudioのパブリックLinuxバージョンのリリース以来、Linuxカーネルの再チェックに関する記事は時間の問題に過ぎません。 世界中の専門家によって書かれたプロジェクトであり、さまざまな分野の多数の人々が使用し、さまざまなツールで定期的にチェックおよびテストされます。このようなプロジェクトのテストは、静的アナライザーにとって深刻なテストになります。 そのような状況でPVS-Studioはどのようなエラーを検出できますか？

チェックしたとおり

Linuxカーネルは既にテスト済みです。 それ以来、多くの変更が行われました-現在、OSのチェックは他のプロジェクトのチェックと同じくらい簡単で便利です

pvs-studio-analyzer trace - make pvs-studio-analyzer analyze -o /path/to/report.log -j8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Linuxでアナライザーを適応およびテストするのに数か月しかかかりませんでしたが、最近まではWindowsでしか利用できませんでした。 今回は、カーネルのチェックが桁違いに簡単になったことがわかりました。



検証のために、バージョン4.9-rc4（commit bc33b0ca11e3df467777a4fa7639ba488c9d4911）が使用されました。



記事を書くために、1-2レベルの汎用診断のみが表示されました。 コードの高品質に注目する価値があります-実際の欠陥を示す警告の密度は非常に低いです。



この記事では、実際のエラー/タイプミスを示す可能性が最も高い警告を選択しました。 アナライザーは、有用な警告に加えて、誤ったアラームを生成したり、設計が不十分なコードや「悪臭」コードを識別しますが、それでも本当に誤っているわけではありません。



残念ながら、Linuxでの誤検知の数は、私たちが望むよりも多くなっています。 これは、Linuxシステム用に設計されたアナライザーバージョンの若者によるものだと思います。 私たちは、誤検知の数を最小限に抑える素晴らしい仕事をしてきました。 Linuxコードは、アナライザーを改善し、アナライザーに多くの便利な変更を加えるのを助けてくれました。

タイプミス

エラーの最も一般的なカテゴリは、一般的なタイプミスとコピーペーストに関連しています。 以前に私たちの記事を読んだことがあるなら、すでにこれを見たことがあると思います。 それらは、あらゆる言語のあらゆるオペレーティングシステム上のあらゆるプロジェクトに登場します。 このようなエラーは、静的アナライザーの可能性を明らかにします。他のツールでそれらを見つけることははるかに困難です。 Linuxカーネルでそれらがどのように使用されているかを見てみましょう。



PVS-Studio警告： V581互いに並んでいる「if」演算子の条件式は同一です。 チェック行：2384、2390。debug.c 2390

 int dbg_check_nondata_nodes_order(....) { .... sa = container_of(cur, struct ubifs_scan_node, list); sb = container_of(cur->next, struct ubifs_scan_node, list); if (sa->type != UBIFS_INO_NODE && sa->type != UBIFS_DENT_NODE && sa->type != UBIFS_XENT_NODE) { ubifs_err(c, "bad node type %d", sa->type); ubifs_dump_node(c, sa->node); return -EINVAL; } if (sa->type != UBIFS_INO_NODE && sa->type != UBIFS_DENT_NODE && sa->type != UBIFS_XENT_NODE) { ubifs_err(c, "bad node type %d", sb->type); ubifs_dump_node(c, sb->node); return -EINVAL; } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーは、2つの同一の条件が連続してあることを訴えます。明らかに、2番目にsaをsbに変更するのを忘れていました。 それでは、誰がクールなプロジェクトにコピーアンドペーストしないと言うでしょうか？



PVS-Studio警告： V666関数 'strncmp'の3番目の引数を調べることを検討してください。 値が、最初の引数で渡された文字列の長さと一致しない可能性があります。 spectrum.c 341

 static ssize_t write_file_spec_scan_ctl(struct file *file, const char __user *user_buf, size_t count, loff_t *ppos) { struct ath10k *ar = file->private_data; char buf[32]; ssize_t len; int res; len = min(count, sizeof(buf) - 1); if (copy_from_user(buf, user_buf, len)) return -EFAULT; buf[len] = '\0'; mutex_lock(&ar->conf_mutex); if (strncmp("trigger", buf, 7) == 0) { .... } else if (strncmp("background", buf, 9) == 0) { res = ath10k_spectral_scan_config(ar, SPECTRAL_BACKGROUND); } else if (strncmp("manual", buf, 6) == 0) { res = ath10k_spectral_scan_config(ar, SPECTRAL_MANUAL); } else if (strncmp("disable", buf, 7) == 0) { res = ath10k_spectral_scan_config(ar, SPECTRAL_DISABLED); } else { res = -EINVAL; } mutex_unlock(&ar->conf_mutex); if (res < 0) return res; return count; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラーの古典的な形式：2つの引数を関数に渡す必要があります：文字列へのポインターとその長さ。 多くの場合、リテラルが引数である場合、カウントの長さは遅延し、数字のみを書き込みます。 ヒューマンファクターが作用します：それらはしばしば間違えられます。



コードのstrncmpが一列に並んでいます。 リテラルはそれぞれに渡されます。 また、 strncmp（「背景」、buf、9）で長さが正しく計算されていません。「背景」という単語は9文字ではなく10文字で構成されています。



PVS-Studio警告： V666関数 'memcpy'の3番目の引数を調べることを検討してください。 値が、2番目の引数で渡された文字列の長さと一致しない可能性があります。 dpt_i2o.c 403

 static void adpt_inquiry(adpt_hba* pHba) { .... memset(pHba->detail, 0, sizeof(pHba->detail)); memcpy(&(pHba->detail), "Vendor: Adaptec ", 16); memcpy(&(pHba->detail[16]), " Model: ", 8); memcpy(&(pHba->detail[24]), (u8*) &buf[16], 16); memcpy(&(pHba->detail[40]), " FW: ", 4); // <= memcpy(&(pHba->detail[44]), (u8*) &buf[32], 4); pHba->detail[48] = '\0'; /* precautionary */ .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別の例。 文字列「FW：」は5文字で、4文字ではありません。



そのようなエラーを取り除く方法は？ Cでは、次のようなマクロを使用できます。

 #define str_len(S) (sizeof(S) / sizeof((S)[0]))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、このようなマクロを使用すること自体が危険です。コンパイラー固有のチェックを追加して、渡された引数が実際に配列であることを確認することをお勧めします。



C ++リーダーの場合、std :: string_viewをお勧めします。これは最終的にC ++ 17に登場しました。 ポインターと長さのペアを文字列関数に渡さないことをお勧めします。 ただし、配列のサイズを手動で計算する必要がある場合（たとえば、memcpy関数に渡すため）、std :: size（array）またはその類似物を使用できます：リテラルの場合、サイズはコンパイル時に計算されます。



コードの繰り返しを避け、コンパイル時の計算に言語ツール（マクロまたはテンプレート）を使用するのを怠らないでください！



PVS-Studio警告： V653 2つの部分で構成される疑わしい文字列は、配列の初期化に使用されます。 コンマが欠落している可能性があります。 このリテラルの検査を検討してください： "30min" "No timeout"。 lp8788-charger.c 657

 static ssize_t lp8788_show_eoc_time(struct device *dev, struct device_attribute *attr, char *buf) { struct lp8788_charger *pchg = dev_get_drvdata(dev); char *stime[] = { "400ms", "5min", "10min", "15min", "20min", "25min", "30min" "No timeout" }; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご存知のように、行に記述された2つのリテラルは連結されています。 これにより、マクロなどで便利に使用できます。 このようなリテラルの配列を作成すると、危険が生じます。コンマをスキップして、予期しない結果を得ることができます。



この場合、最後の2つのリテラルは「結合」し、「30minNoタイムアウト」を取得します。 これは二重の間違いです。 まず、テキストが正しくありません。次に、配列内の1つの要素が欠落しているため、配列が流出する可能性があります。



別のフォーマット方法を使用することをお勧めします。そのようなエラーは顕著になります。

 char *stime[] = { "400ms" , "5min" , "10min" , "15min" , "20min" , "25min" , "30min" "No timeout" };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の同僚のAndrei Karpovは、この表形式コード設計の方法について詳しく書いています。 私は彼の小さな本からN13章を読むことを提案します。



PVS-Studio 警告 ： V764 「ahc_9005_subdevinfo_valid」関数に渡される引数の誤った順序の可能性：「デバイス」および「ベンダー」。 aic7xxx_pci.c 695

 const struct ahc_pci_identity * ahc_find_pci_device(ahc_dev_softc_t pci) { .... if (ahc_get_pci_function(pci) > 0 && ahc_9005_subdevinfo_valid(device, vendor, // <= subdevice, subvendor) && SUBID_9005_MFUNCENB(subdevice) == 0) return (NULL); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アナライザーが何を誓うかを理解するのが難しい場合があります。 ちなみに、これはよく起こります：分析者が彼に書いたものを人が理解せず、「偽陽性」のレポートを私たちに送りましたが、実際にはエラーがあります。 ここでは、これは誤検知であるように思われました。関数はコード内で少し高く定義されており、すべてのパラメーターが設定されています。 これは次のようなものです。

 static int ahc_9005_subdevinfo_valid(uint16_t device, uint16_t vendor, uint16_t subdevice, uint16_t subvendor) { .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題は何ですか？ この関数の宣言はさらに高く、これらの引数はそこで混同されていることがわかります。 実際、プログラムのロジックには何も問題はありませんが、誰も混乱させたり混乱させたりしないように修正することをお勧めします。

 static int ahc_9005_subdevinfo_valid(uint16_t vendor, uint16_t device, uint16_t subvendor, uint16_t subdevice);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし面白いのは、ここでのエラーはすでにあったということです。パラメーターが本当に混同されていて、広告を修正するのを忘れていました。 アナライザーもこの場所を見つけたのは良いことです。



警告PVS-Studio： V549 'memcpy'関数の最初の引数は2番目の引数と同じです。 wilc_wfi_cfgoperations.c 1345

 static int del_pmksa(struct wiphy *wiphy, struct net_device *netdev, struct cfg80211_pmksa *pmksa) { .... for (; i < (priv->pmkid_list.numpmkid - 1); i++) { memcpy(priv->pmkid_list.pmkidlist[i].bssid, priv->pmkid_list.pmkidlist[i + 1].bssid, ETH_ALEN); memcpy(priv->pmkid_list.pmkidlist[i].pmkid, priv->pmkid_list.pmkidlist[i].pmkid, PMKID_LEN); } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後のmemcpyはポインターに一致します。 おそらく、彼らは前の表現との類推で書きたいと思ったでしょう。

 memcpy(priv->pmkid_list.pmkidlist[i].pmkid, priv->pmkid_list.pmkidlist[i + 1].pmkid, PMKID_LEN);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

未使用の変数

PVS-Studio警告： V575 「strncasecmp」関数は「0」要素を処理します。 3番目の引数を調べます。 linux_wlan.c 1121

 static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd) { u8 *buff = NULL; s8 rssi; u32 size = 0, length = 0; struct wilc_vif *vif; s32 ret = 0; struct wilc *wilc; vif = netdev_priv(ndev); wilc = vif->wilc; if (!wilc->initialized) return 0; switch (cmd) { case SIOCSIWPRIV: { struct iwreq *wrq = (struct iwreq *)req; size = wrq->u.data.length; if (size && wrq->u.data.pointer) { buff = memdup_user(wrq->u.data.pointer, wrq->u.data.length); if (IS_ERR(buff)) return PTR_ERR(buff); if (strncasecmp(buff, "RSSI", length) == 0) { // <= .... } } } .... } done: kfree(buff); return ret; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

strncasecmp関数には、長さの引数として0が渡されました。 コード内に可変長が変わる場所はないため、その値はゼロのままです。 おそらくsizeを使用する必要があります。



PVS-Studio警告： V751パラメーター「LCDheight」は関数本体内では使用されません。 init.c 339

 static unsigned short SiS_GetModeID(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDisplay, int Depth, bool FSTN, int LCDwidth, int LCDheight) { unsigned short ModeIndex = 0; switch(HDisplay) { case 320: if(VDisplay == 200) ModeIndex = ModeIndex_320x200[Depth]; else if(VDisplay == 240) { if((VBFlags & CRT2_LCD) && (FSTN)) ModeIndex = ModeIndex_320x240_FSTN[Depth]; else ModeIndex = ModeIndex_320x240[Depth]; } break; case 400: if((!(VBFlags & CRT1_LCDA)) || ((LCDwidth >= 800) && (LCDwidth >= 600))) { // <= if(VDisplay == 300) ModeIndex = ModeIndex_400x300[Depth]; } break; case 512: if((!(VBFlags & CRT1_LCDA)) || ((LCDwidth >= 1024) && (LCDwidth >= 768))) { // <= if(VDisplay == 384) ModeIndex = ModeIndex_512x384[Depth]; } break; .... } return ModeIndex; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関数で常に未使用であるとは限らないパラメーターはエラーです。 かなり古いAPIでは、パラメーターが不要になり、上書きされるか、単に使用されない状況が発生します。 しかし、この断片を詳しく見てみましょう。ここでは、高さを比較するのを忘れていました。 代わりに、 「（A> 5）&&（A> 3）」という形式の比較が登場しましたが 、それ自体は冗長です。

操作の優先順位に関する混乱

警告PVS-Studio： V502 「？：」演算子は、予想とは異なる方法で動作する可能性があります。 「？：」演算子の優先順位は「|」よりも低い 演算子。 core.c 1046

 static int nvme_pr_preempt(struct block_device *bdev, u64 old, u64 new, enum pr_type type, bool abort) { u32 cdw10 = nvme_pr_type(type) << 8 | abort ? 2 : 1; return nvme_pr_command(bdev, cdw10, old, new, nvme_cmd_resv_acquire); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cの三項演算子は非常に危険な演算子です。 PVS-Studioの最初の汎用診断の1つが彼に捧げられているだけではありません。 事実、彼の優先度は低く、複雑な式では混乱しやすく、計算の順序がまったく異なります。 したがって、疑問がある場合は括弧を使用することをお勧めします。

疑わしいチェック

PVS-Studio 警告 ： V517 「if（A）{...} else if（A）{...}」パターンの使用が検出されました。 論理エラーが存在する可能性があります。 行を確認してください：375、377。trx.c 375

 bool rtl92ee_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *status, struct ieee80211_rx_status *rx_status, u8 *pdesc, struct sk_buff *skb) { struct rtl_priv *rtlpriv = rtl_priv(hw); struct rx_fwinfo *p_drvinfo; struct ieee80211_hdr *hdr; u32 phystatus = GET_RX_DESC_PHYST(pdesc); .... status->macid = GET_RX_DESC_MACID(pdesc); if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc)) status->wake_match = BIT(2); else if (GET_RX_STATUS_DESC_MAGIC_MATCH(pdesc)) status->wake_match = BIT(1); else if (GET_RX_STATUS_DESC_UNICAST_MATCH(pdesc)) status->wake_match = BIT(0); else status->wake_match = 0; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

側から見ると、ここで何が間違っているのかを理解することは困難です。 マクロGET_RX_STATUS_DESC_MAGIC_MATCHを使用して、同じチェックが2回行われます。 彼の広告を見ると、他の2つのマクロが表示されます。

 #define GET_RX_STATUS_DESC_PATTERN_MATCH(__pdesc) LE_BITS_TO_4BYTE(__pdesc+12, 29, 1) #define GET_RX_STATUS_DESC_UNICAST_MATCH(__pdesc) LE_BITS_TO_4BYTE(__pdesc+12, 30, 1) #define GET_RX_STATUS_DESC_MAGIC_MATCH(__pdesc) LE_BITS_TO_4BYTE(__pdesc+12, 31, 1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おそらく、元のフラグメントで欠落しているGET_RX_STATUS_DESC_PATTERN_MATCHを使用したかったのでしょう。 それ以外の場合、このチェックは単に無意味です。



PVS-Studio 警告 ： V547式 '（ptr [3]＆0x1E）！= 0x03'は常にtrueです。 sd.c 4115

 int ext_sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8 cmd_idx, u32 arg, u8 rsp_type, u8 *rsp, int rsp_len, bool special_check) { int retval; int timeout = 100; u16 reg_addr; u8 *ptr; .... if (cmd_idx == SELECT_CARD) { if (rsp_type == SD_RSP_TYPE_R2) { if ((ptr[3] & 0x1E) != 0x04) { rtsx_trace(chip); return STATUS_FAIL; } } else if (rsp_type == SD_RSP_TYPE_R0) { if ((ptr[3] & 0x1E) != 0x03) { // <= rtsx_trace(chip); return STATUS_FAIL; } } } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラーはビット操作に関連しています。 1ビットに起因する0x1Eとのビットごとの結合の結果は、値0x03と決して等しくなりません。

PVS-Studio 警告 ： V517 「if（A）{...} else if（A）{...}」パターンの使用が検出されました。 論理エラーが存在する可能性があります。 チェック行：1277、1282。ks_wlan_net.c 1277

 static int ks_wlan_set_power(struct net_device *dev, struct iw_request_info *info, struct iw_param *vwrq, char *extra) { struct ks_wlan_private *priv = (struct ks_wlan_private *)netdev_priv(dev); short enabled; if (priv->sleep_mode == SLP_SLEEP) { return -EPERM; } /* for SLEEP MODE */ enabled = vwrq->disabled ? 0 : 1; if (enabled == 0) { /* 0 */ priv->reg.powermgt = POWMGT_ACTIVE_MODE; } else if (enabled) { /* 1 */ if (priv->reg.operation_mode == MODE_INFRASTRUCTURE) priv->reg.powermgt = POWMGT_SAVE1_MODE; else return -EINVAL; } else if (enabled) { /* 2 */ if (priv->reg.operation_mode == MODE_INFRASTRUCTURE) priv->reg.powermgt = POWMGT_SAVE2_MODE; else return -EINVAL; } else return -EINVAL; hostif_sme_enqueue(priv, SME_POW_MNGMT_REQUEST); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例を次のように減らします。

 enabled = vwrq->disabled ? 0 : 1; if (enabled == 0) { /* 0 */ .... } else if (enabled) { /* 1 */ .... } else if (enabled) { /* 2 */ .... } else ....
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは非常に奇妙に見えます。 値の範囲は上記の式によって明確にネゴシエートされているようです： enabledは0または1です。 ただし、最大4つの値がチェックされます。 同時に、コメントは干渉するだけです。数値が変数の可能な値を示す場合は、実際には対応していません。1と2のチェックは同じ方法で書き込まれます。



PVS-Studio 警告 ： V517 「if（A）{...} else if（A）{...}」パターンの使用が検出されました。 論理エラーが存在する可能性があります。 行を確認してください：422、424。Hal8188ERateAdaptive.c 422

 static int odm_ARFBRefresh_8188E( struct odm_dm_struct *dm_odm, struct odm_ra_info *pRaInfo) { /* Wilson 2011/10/26 */ .... if (pRaInfo->HighestRate > 0x13) pRaInfo->PTModeSS = 3; else if (pRaInfo->HighestRate > 0x0b) pRaInfo->PTModeSS = 2; else if (pRaInfo->HighestRate > 0x0b) pRaInfo->PTModeSS = 1; else pRaInfo->PTModeSS = 0; .... return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2つの条件が連続する別の場所。 ボディが異なることに注意してください。 ここに本当の間違いがあるのか​​、それとも未使用のコードなのかを言うのは困難です。これはすでにプロジェクト開発者の仕事です。 アナライザーのタスクは、疑わしい場所に注意を払うことです。



警告PVS-Studio： V734過剰なチェック。 サブストリング「interleaver」および「deinterleaver」の検索を含む条件を調べます。 sst-atom-controls.c 1449

 static int sst_fill_widget_module_info( struct snd_soc_dapm_widget *w, struct snd_soc_platform *platform) { struct snd_kcontrol *kctl; int index, ret = 0; struct snd_card *card = platform->component.card->snd_card; char *idx; down_read(&card->controls_rwsem); list_for_each_entry(kctl, &card->controls, list) { .... } else if (strstr(kctl->id.name, "interleaver")) { struct sst_enum *e = (void *)kctl->private_value; e->w = w; } else if (strstr(kctl->id.name, "deinterleaver")) { struct sst_enum *e = (void *)kctl->private_value; e->w = w; } .... } up_read(&card->controls_rwsem); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフラグメントでは、1行にいくつかのサブストリングが存在するかどうかが連続してチェックされます。 わかりやすくするために、興味のある部分文字列のみを残しました。 インターリーバーが見つからなかった場合、 インターリーバーのサブストリングが完全になくなっているため、 deinterleaverを探すことは意味がありません。 したがって、このコードセクションは機能しませんが、ifとelseの本体が同じであるため、これは怖くありません。 これは単なる冗長コードです。



PVS-Studioの 警告 ： V547式「ブロック」は常に真です。 svclock.c 873

 void nlmsvc_grant_reply(struct nlm_cookie *cookie, __be32 status) { struct nlm_block *block; dprintk("grant_reply: looking for cookie %x, s=%d \n", *(unsigned int *)(cookie->data), status); if (!(block = nlmsvc_find_block(cookie))) return; if (block) { if (status == nlm_lck_denied_grace_period) { /* Try again in a couple of seconds */ nlmsvc_insert_block(block, 10 * HZ); } else { /* Lock is now held by client, or has been rejected. * In both cases, the block should be removed. */ nlmsvc_unlink_block(block); } } nlmsvc_release_block(block); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例は、 ASTをバイパスして、静的アナライザーがパターンベースの分析を実行するのに十分でない理由を示しています。 制御フロー分析とデータフロー分析を実行できることが重要です。 block == NULLの時点で戻りが発生するため、コードをさらに下に移動すると、ポインターがゼロ以外であることを確認できます。 そして、 NULLのチェックに遭遇すると、ここで何かが間違っていることを明確に理解します。



ここでは、2番目のポインターチェックは不要なようです。 ただし、ここで別の変数を確認したい場合はどうでしょうか？ 誰が知っているか...分析者は、検証のためにこのコードを開発者に明確に提供すべきです。



同様の状況：



PVS-Studio警告： V547式 'sym'は常に真です。 menu.c 498

 bool menu_is_visible(struct menu *menu) { struct menu *child; struct symbol *sym; .... if (!sym || sym_get_tristate_value(menu->sym) == no) // <= return false; for (child = menu->list; child; child = child->next) { if (menu_is_visible(child)) { if (sym) // <= sym->flags |= SYMBOL_DEF_USER; return true; } } return false; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マクロエラー

警告PVS-Studio： V733マクロを展開した結果、評価順序が間違っている可能性があります。 式を確認してください：request-> rq_timeout + 5 *1000。niobuf.c 637

 #define CFS_FAIL_TIMEOUT(id, secs) \ cfs_fail_timeout_set(id, 0, secs * 1000, CFS_FAIL_LOC_NOSET) #define OBD_FAIL_TIMEOUT(id, secs) \ CFS_FAIL_TIMEOUT(id, secs) int ptl_send_rpc(struct ptlrpc_request *request, int noreply) { .... OBD_FAIL_TIMEOUT(OBD_FAIL_PTLRPC_DELAY_SEND, request->rq_timeout + 5); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、そのようなエラーは非常にまれです。 その前に、私は実際のプロジェクトでこの診断の操作を1つだけ見ました。それがFreeBSDだったことは注目に値します 。 マクロの定義に誤りがありました。すべてのパラメーターを角括弧で囲むのが最善です。 これが行われない場合、次のケースが考えられます。「sec + 1000」を「x + 5」に置き換えると、「x + 5 * 1000」が得られますが、これは明らかに著者が期待したものではありません。

意味のないmemset

PVS-Studio警告： V597コンパイラは、「ps」バッファをフラッシュするために使用される「memset」関数呼び出しを削除できました。 プライベートデータを消去するには、memset_s（）関数を使用する必要があります。 atom.c 1383

 int amdgpu_atom_asic_init(struct atom_context *ctx) { int hwi = CU16(ctx->data_table + ATOM_DATA_FWI_PTR); uint32_t ps[16]; int ret; memset(ps, 0, 64); ps[0] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFSCLK_PTR)); ps[1] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFMCLK_PTR)); if (!ps[0] || !ps[1]) return 1; if (!CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_INIT)) return 1; ret = amdgpu_atom_execute_table(ctx, ATOM_CMD_INIT, ps); if (ret) return ret; memset(ps, 0, 64); // <= return ret; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

戻る前にmemsetを追加しても意味がありません。コンパイラは、この操作によってプログラムの表示状態が変更されないことを確認し（配列はまだスコープ外になります）、削除します。 重要なデータを消去する必要がある場合は、 memset_sを使用するか、独自のアナログを作成する必要があります。



ところで、このエラーは実際には脆弱性です。 上書きされるデータは上書きされません。 詳細は、 V597診断の説明に記載されています。 ところで、これは非常に一般的な脆弱性です： 証拠 。

memcmpの危険な使用

PVS-Studio警告： V642 「memcmp」関数の結果を「unsigned char」型変数に保存するのは不適切です。 プログラムのロジックを壊して、重要なビットが失われる可能性があります。 host.c 1789

 static void power_control_timeout(unsigned long data) { .... u8 other = memcmp(requester->frame_rcvd.iaf.sas_addr, iphy->frame_rcvd.iaf.sas_addr, sizeof(requester->frame_rcvd.iaf.sas_addr)); if (other == 0) { .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

返されたmemcmp値に関するドキュメントの説明を注意深く読むと、特定の範囲についての保証がないことがわかります。関数はその型内の任意の数を返すことができます。 そして、これは常に-1、0、1ではありません。 したがって、その値をより小さな型の変数に格納することは不可能です。最上位の桁が失われると、若い桁はゼロになる可能性があります。 同様のエラーがMySQL / MariaDBに脆弱性をもたらしました。

おわりに

既に述べたように、Linuxは非常に高品質で十分にテストされたプロジェクトです。 それに間違いを見つけることは、最も些細なことでさえ、すでに誇りの理由です。 これは、デバッグおよびテストの前に検出できるエラーの数を考慮する理由でもあります。静的分析が重要なのはこの役割です。 これを確認するには、PVS-Studioを試してください。 Linuxの場合は、メールでお問い合わせいただくと、アナライザーの試用版を入手できます。 また、非営利プロジェクトの場合は、PVS-Studioを無料で使用できます。 この記事に精通し、オープンで無料のユーティリティhow-to-use-pvs-studio-freeを使用してください 。







この記事を英語を話す聴衆と共有したい場合は、翻訳へのリンクを使用してください：Pavel Belikov。 Linuxカーネル、PVS-StudioのLinuxバージョンでテスト済み