हमने पीवीएस-स्टूडियो का उपयोग करके एंड्रॉइड स्रोत कोड की जांच की, या कोई भी सही नहीं है

कोड की गुणवत्ता को नियंत्रित करने में मदद करने के लिए प्रोग्रामिंग पद्धति और उपकरणों के उपयोग के बिना बड़ी जटिल परियोजनाओं का विकास असंभव है। सबसे पहले, यह एक सक्षम कोडिंग मानक, कोड समीक्षा, इकाई परीक्षण, स्थिर और गतिशील कोड विश्लेषक है। यह सब विकास के शुरुआती चरणों में कोड में दोषों की पहचान करने में मदद करता है। यह लेख एंड्रॉइड ऑपरेटिंग सिस्टम के कोड में त्रुटियों और संभावित कमजोरियों का पता लगाने के लिए पीवीएस-स्टूडियो स्थिर विश्लेषक की क्षमताओं को प्रदर्शित करता है। हमें उम्मीद है कि लेख पाठकों को स्थैतिक कोड विश्लेषण की कार्यप्रणाली की ओर आकर्षित करेगा और वे इसे अपनी परियोजनाओं को विकसित करने की प्रक्रिया में लागू करना चाहेंगे।

परिचय

Tizen ऑपरेटिंग सिस्टम में त्रुटियों के बारे में एक बड़े लेख के लेखन में एक साल बीत चुका है, और मैं फिर से कुछ ऑपरेटिंग सिस्टम का समान रूप से दिलचस्प अध्ययन करना चाहता था। चुनाव Android पर गिर गया।

एंड्रॉइड ऑपरेटिंग सिस्टम कोड गुणवत्ता वाला है, अच्छी तरह से परीक्षण किया गया है। विकास के दौरान, कम से कम एक कवरेज स्टैटिक कोड विश्लेषक का उपयोग किया जाता है, जैसा कि प्रपत्र की टिप्पणियों द्वारा स्पष्ट किया गया है:

/* Coverity: [FALSE-POSITIVE error] intended fall through */ /* Missing break statement between cases in switch statement */ /* fall through */ 

सामान्य तौर पर, यह एक दिलचस्प, उच्च-गुणवत्ता वाली परियोजना है, और इसमें त्रुटियां ढूंढना हमारे पीवीएस-स्टूडियो स्थैतिक विश्लेषक के लिए एक चुनौती है।

मुझे लगता है कि केवल लेख की मात्रा से पाठक समझता है कि पीवीएस-स्टूडियो विश्लेषक ने एक उत्कृष्ट काम किया और इस ऑपरेटिंग सिस्टम के कोड में बहुत सारे दोष पाए गए।

सामान्य निर्बलता

लेख में आपको कॉमन वीकनेस एन्यूमरेशन (CWE) के संदर्भ मिलेंगे। आइए हम इस सूची को संदर्भित करने का कारण बताते हैं और यह सुरक्षा के दृष्टिकोण से क्यों महत्वपूर्ण है।

अक्सर कार्यक्रमों में भेद्यता का कारण परिस्थितियों का कुछ मुश्किल सेट नहीं होता है, लेकिन एक सॉफ़्टवेयर की त्रुटि है। यहाँ यह उद्धरण prqa.com से उद्धृत करना उचित होगा:

नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड एंड टेक्नोलॉजी (एनआईएसटी) की रिपोर्ट है कि 64% सॉफ्टवेयर भेद्यता प्रोग्रामिंग त्रुटियों से उपजी है और सुरक्षा सुविधाओं की कमी नहीं है।

आप लेख में पढ़ सकते हैं " कैसे पीवीएस-स्टूडियो कमजोरियों को खोजने में मदद कर सकते हैं? " सरल त्रुटियों के कुछ उदाहरणों के साथ जो MySQL, iOS, NAS, इल्यूमोस-गेट जैसी परियोजनाओं में कमजोरियों का कारण बने।

तदनुसार, कई कमजोरियों को समय में सामान्य त्रुटियों का पता लगाकर और उन्हें ठीक करके समाप्त किया जा सकता है। और यहां कॉमन वेकनेस एन्यूमरेशन दृश्य में प्रवेश करता है।

त्रुटियां अलग हैं, और सुरक्षा की दृष्टि से सभी त्रुटियां खतरनाक नहीं हैं। ऐसी त्रुटियाँ जो संभावित रूप से कमजोरियाँ पैदा कर सकती हैं, वे सामान्य दुर्बलता में एकत्र की जाती हैं। यह सूची अपडेट की जा रही है, और संभवतः ऐसी त्रुटियां हैं जो कमजोरियों को जन्म दे सकती हैं, लेकिन उन्हें अभी तक इस सूची में शामिल नहीं किया गया है।

हालांकि, अगर त्रुटि को CWE के अनुसार वर्गीकृत किया गया है, तो इसका मतलब है कि यह सैद्धांतिक रूप से संभव है कि इसे एक भेद्यता ( CVE ) के रूप में शोषण किया जा सकता है। हां, इस बात की संभावना कम ही है। बहुत कम ही, सीडब्ल्यूई सीवीई में बदल जाता है। हालांकि, यदि आप अपने कोड को कमजोरियों से बचाना चाहते हैं, तो आपको, यदि संभव हो तो, CWE में वर्णित कई बगों को ढूंढना चाहिए और उन्हें ठीक करना चाहिए।

योजनाबद्ध रूप से, पीवीएस-स्टूडियो, त्रुटियों, सीडब्ल्यूई और सीवीई के बीच का संबंध चित्र में दिखाया गया है:

कुछ त्रुटियों को CWE के रूप में वर्गीकृत किया गया है। PVS-Studio इनमें से कई त्रुटियों का पता लगा सकता है, जिससे इनमें से कुछ दोषों को भेद्यता (CVE) बनने से रोका जा सकता है।

हम कह सकते हैं कि पीवीएस-स्टूडियो नुकसान पहुंचाने से पहले कई संभावित कमजोरियों की पहचान करता है। इस प्रकार, पीवीएस-स्टूडियो एक स्थैतिक अनुप्रयोग सुरक्षा परीक्षण उपकरण ( एसएएसटी ) है।

अब, मुझे लगता है, यह स्पष्ट है कि, त्रुटियों का वर्णन करते समय, मैंने यह नोट करना महत्वपूर्ण समझा कि उन्हें CWE के अनुसार कैसे वर्गीकृत किया जाता है। इस तरह से महत्वपूर्ण परियोजनाओं में एक स्थिर कोड विश्लेषक के उपयोग के महत्व को दिखाना आसान है, जो ऑपरेटिंग सिस्टम स्पष्ट रूप से संबंधित हैं।

Android चेक

परियोजना का विश्लेषण करने के लिए, मैंने पीवीएस-स्टूडियो विश्लेषक संस्करण 6.24 का उपयोग किया। विश्लेषक वर्तमान में निम्नलिखित भाषाओं और संकलक का समर्थन करता है:

• विंडोज। विज़ुअल स्टूडियो 2010-2017 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
• विंडोज। आईएआर एंबेडेड वर्कबेंच, एआर / सी के लिए सी / सी ++ कंपाइलर, सी ++
• विंडोज / लिनक्स केएल ilविज़न, डीएस-एमडीके, एआरएम कंपाइलर 5/6 सी, सी ++
• विंडोज / लिनक्स टेक्सास इंस्ट्रूमेंट्स कोड कम्पोज़र स्टूडियो, एआरएम कोड जेनरेशन टूल्स सी, सी ++
• विंडोज / लिनक्स / मैकओएस। क्लेंग सी, सी ++
• लिनक्स / macOS। जीसीसी सी, सी ++
• विंडोज। MinGW C, C ++

नोट। शायद हमारे कुछ पाठकों ने इस खबर को याद किया है कि हमने macOS के वातावरण में काम का समर्थन किया है और वे इस प्रकाशन में दिलचस्पी लेंगे: " macOS के लिए PVS-Studio रिलीज़: Apple XNU कर्नेल में 64 कमजोरियाँ "।

एंड्रॉइड सोर्स कोड की जांच की प्रक्रिया कोई समस्या नहीं थी, इसलिए मैं उस पर ध्यान नहीं दूंगा। समस्या, बल्कि, अन्य कार्यों के साथ मेरी व्यस्तता थी, यही वजह है कि मुझे रिपोर्ट को ध्यान से देखने के लिए समय और ऊर्जा नहीं मिली जितनी मैं चाहूंगा। हालांकि, एक त्वरित नज़र भी एक ठोस लेख के लिए दिलचस्प त्रुटियों के बड़े संग्रह को इकट्ठा करने के लिए पर्याप्त से अधिक था।

सबसे महत्वपूर्ण बात: मैं एंड्रॉइड डेवलपर्स से न केवल लेख में वर्णित त्रुटियों को ठीक करने के लिए कहता हूं, बल्कि एक अधिक सावधान स्वतंत्र विश्लेषण करने के लिए भी कहता हूं। मैंने विश्लेषक की रिपोर्ट को सतही रूप से देखा और बहुत सी गंभीर त्रुटियों को याद कर सकता था।

पहले परीक्षण में, विश्लेषक बहुत सारी झूठी सकारात्मक चीजों का उत्पादन करेगा, लेकिन यह कोई समस्या नहीं है । हमारी टीम झूठी सकारात्मक की संख्या को कम करने के लिए विश्लेषक को कॉन्फ़िगर करने की सिफारिशों के साथ मदद करने के लिए तैयार है। यदि आवश्यक हो तो हम एक महीने या उससे अधिक के लिए लाइसेंस कुंजी प्रदान करने के लिए भी तैयार हैं। सामान्य तौर पर, हमें लिखें , हम आपकी मदद करेंगे और आपको बताएंगे।

अब देखते हैं कि मैं किन त्रुटियों और संभावित कमजोरियों को खोजने में कामयाब रहा। मुझे आशा है कि आप पीवीएस-स्टूडियो स्टैटिक कोड एनालाइजर का आनंद ले सकते हैं। अच्छा पढ़ा है।

अर्थहीन तुलना

विश्लेषक भावों को असामान्य मानता है यदि वे हमेशा सही या गलत होते हैं। इस तरह की चेतावनियाँ, सामान्य कमजोरी गणना के अनुसार, निम्नानुसार वर्गीकृत की जाती हैं:

• CWE-570 : अभिव्यक्ति हमेशा गलत है
• CWE-571 : अभिव्यक्ति हमेशा सच है

विश्लेषक ऐसी कई चेतावनी देता है, और, दुर्भाग्य से, उनमें से ज्यादातर एंड्रॉइड कोड के लिए झूठे हैं। इस मामले में, विश्लेषक को दोष नहीं देना है। बस कोड जैसा लिखा है।
मैं इसे एक सरल उदाहरण के साथ प्रदर्शित करूंगा।

 #if GENERIC_TARGET const char alternative_config_path[] = "/data/nfc/"; #else const char alternative_config_path[] = ""; #endif CNxpNfcConfig& CNxpNfcConfig::GetInstance() { .... if (alternative_config_path[0] != '\0') { .... } 

यहां विश्लेषक एक चेतावनी देता है: V547 CWE-570 एक्सप्रेशन 'वैकल्पिक_कॉन्फ़िग_पाथ [0]! =' \ 0 '' हमेशा गलत होता है। phNxpConfig.cpp 401

तथ्य यह है कि GENERIC_TARGET मैक्रो परिभाषित नहीं है, और विश्लेषक के दृष्टिकोण से, कोड इस तरह दिखता है:

 const char alternative_config_path[] = ""; .... if (alternative_config_path[0] != '\0') { 

विश्लेषक बस एक चेतावनी जारी करने के लिए बाध्य है, क्योंकि लाइन खाली है, और एक टर्मिनल शून्य हमेशा शून्य ऑफसेट पर स्थित है। इस प्रकार, विश्लेषक चेतावनी जारी करने में औपचारिक रूप से सही है। हालांकि, व्यावहारिक दृष्टिकोण से, इस चेतावनी से कोई लाभ नहीं है।

दुर्भाग्य से, ऐसी स्थितियों के साथ कुछ भी नहीं किया जा सकता है। हमें ऐसी सभी चेतावनियों को व्यवस्थित रूप से समीक्षा करनी होगी और कई स्थानों को झूठी सकारात्मकता के रूप में चिह्नित करना होगा ताकि विश्लेषक अब इन पंक्तियों पर संदेश जारी न करें। यह वास्तव में करने की आवश्यकता है, क्योंकि, व्यर्थ संदेशों के अलावा, बहुत सारे वास्तविक दोष पाए जाएंगे।

मैं ईमानदारी से स्वीकार करता हूं कि मुझे इस प्रकार की चेतावनियों को ध्यान से देखने में कोई दिलचस्पी नहीं थी, और मैं उन पर सतही तौर पर चढ़ गया। हालांकि, यहां तक ​​कि यह दिखाने के लिए पर्याप्त होगा कि ऐसे निदान बहुत उपयोगी हैं और दिलचस्प त्रुटियां पाते हैं।

मैं उस क्लासिक स्थिति से शुरू करना चाहता हूं जब दो वस्तुओं की तुलना करने के कार्य को गलत तरीके से लागू किया जाता है। क्‍यों क्लासिक? यह एक विशिष्ट त्रुटि पैटर्न है जो हम लगातार विभिन्न परियोजनाओं में सामना करते हैं। सबसे अधिक संभावना है, इसकी घटना के तीन कारण हैं:

1. तुलना कार्य सरल हैं और "स्वचालित रूप से" लिखे जाते हैं और कॉपी-पेस्ट तकनीक का उपयोग करते हैं। ऐसा कोड लिखते समय, एक व्यक्ति असावधान होता है और अक्सर टाइपोस बनाता है।
2. आमतौर पर, ऐसे कार्यों के लिए कोड-समीक्षा नहीं की जाती है, क्योंकि यह सरल और उबाऊ कार्यों को देखने के लिए बहुत आलसी है।
3. यूनिट परीक्षण आमतौर पर ऐसे कार्यों के लिए नहीं किए जाते हैं। क्योंकि आलस्य। इसके अलावा, फ़ंक्शन सरल हैं, और प्रोग्रामर यह नहीं सोचते हैं कि उनमें त्रुटियां संभव हैं।

इन विचारों और उदाहरणों को " ईविल तुलना के कार्यों में रहता है " लेख में अधिक विस्तार से वर्णित किया गया है।

 static inline bool isAudioPlaybackRateEqual( const AudioPlaybackRate &pr1, const AudioPlaybackRate &pr2) { return fabs(pr1.mSpeed - pr2.mSpeed) < AUDIO_TIMESTRETCH_SPEED_MIN_DELTA && fabs(pr1.mPitch - pr2.mPitch) < AUDIO_TIMESTRETCH_PITCH_MIN_DELTA && pr2.mStretchMode == pr2.mStretchMode && pr2.mFallbackMode == pr2.mFallbackMode; } 

तो, इससे पहले कि हम टाइप करें AudioPlaybackRate की दो वस्तुओं की तुलना करने का क्लासिक कार्य। और, जैसा कि मुझे लगता है, पाठक का अनुमान है कि यह गलत है। PVS-Studio विश्लेषक दो टाइपो को तुरंत नोटिस करता है:

• V501 CWE-571 बाईं और '==' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्ति हैं: pr2.mStretchMode == pr2.mStretchMode AudioResamplerPublic.b 107
• V501 CWE-571 बाईं और '==' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्ति हैं: pr2.mFallbackMode == pr2.mFallbackMode AudioResamplerPublic.b 108

Pr2.mStretchMode फ़ील्ड और pr2.mFallbackMode फ़ील्ड की तुलना स्वयं से की जाती है। यह पता चला है कि फ़ंक्शन वस्तुओं की तुलना सही ढंग से नहीं करता है।

निम्न व्यर्थ की तुलना एक फंक्शन में रहती है जो एक फाइल में फिंगरप्रिंट जानकारी संग्रहीत करता है।

 static void saveFingerprint(worker_thread_t* listener, int idx) { .... int ns = fwrite(&listener->secureid[idx], sizeof(uint64_t), 1, fp); .... int nf = fwrite(&listener->fingerid[idx], sizeof(uint64_t), 1, fp); if (ns != 1 || ns !=1) // <= ALOGW("Corrupt emulator fingerprints storage; " "could not save fingerprints"); fclose(fp); return; } 

एक बार में दो डायग्नोस्टिक्स द्वारा इस कोड में एक विसंगति का पता लगाया जाता है:

• V501 CWE-570 बाईं और 'के दाईं ओर समान उप-अभिव्यक्तियाँ हैं' || संचालक: ns! = 1 || ns! = 1 फ़िंगरप्रिंट.c 126
• V560 CWE-570 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है: ns! = 1. फिंगरप्रिंट सी। 126

उस स्थिति से निपटने के लिए नहीं है जब फाइटाइट फ़ंक्शन के लिए दूसरा कॉल किसी फ़ाइल में डेटा नहीं लिख सकता है। दूसरे शब्दों में, चर nf के मूल्य की जाँच नहीं की जाती है। सही जाँच इस तरह दिखनी चाहिए:

 if (ns != 1 || nf != 1) 

हम & ऑपरेटर के उपयोग से जुड़ी अगली त्रुटि के लिए आगे बढ़ते हैं।

 #define O_RDONLY 00000000 #define O_WRONLY 00000001 #define O_RDWR 00000002 static ssize_t verity_read(fec_handle *f, ....) { .... /* if we are in read-only mode and expect to read a zero block, skip reading and just return zeros */ if (f->mode & O_RDONLY && expect_zeros) { memset(data, 0, FEC_BLOCKSIZE); goto valid; } .... } 

PVS-Studio चेतावनी: V560 CWE-570 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है: f-> मोड और 00000000. fec_read.cpp 322

ध्यान दें कि स्थिर O_RDONLY शून्य है। इससे अभिव्यक्ति f-> मोड और O_RDONLY व्यर्थ हो जाती है, क्योंकि यह हमेशा 0. होता है। यह पता चलता है कि यदि कथन की स्थिति कभी संतुष्ट नहीं है, और कथन-सत्य मृत कोड है।

सही जाँच इस तरह होनी चाहिए:

 if (f->mode == O_RDONLY && expect_zeros) { 

अब एक क्लासिक टाइपो को देखते हैं जब हम हालत का हिस्सा लिखना भूल गए।

 enum { .... CHANGE_DISPLAY_INFO = 1 << 2, .... }; void RotaryEncoderInputMapper::configure(nsecs_t when, const InputReaderConfiguration* config, uint32_t changes) { .... if (!changes || (InputReaderConfiguration::CHANGE_DISPLAY_INFO)) { .... } 

PVS-Studio चेतावनी: V768 CWE-571 गणना निरंतर 'CHANGE_DISPLAY_INFO' का उपयोग बूलियन-प्रकार के एक चर के रूप में किया जाता है। InputReader.cpp 3016

यह शर्त हमेशा सही होती है, क्योंकि ऑपरेंड InputReaderConfiguration :: CHANGE_DISPLAY_INFO लगातार 4 के बराबर है।

यदि आप देखते हैं कि पड़ोस में कोड कैसे लिखा जाता है, तो यह स्पष्ट हो जाता है कि वास्तव में इस तरह की स्थिति होनी चाहिए:

 if (!changes || (changes & InputReaderConfiguration::CHANGE_DISPLAY_INFO)) { 

निम्नलिखित तुलना, जिसका कोई मतलब नहीं है, मैं लूप ऑपरेटर में मिला।

 void parse_printerAttributes(....) { .... ipp_t *collection = ippGetCollection(attrptr, i); for (j = 0, attrptr = ippFirstAttribute(collection); (j < 4) && (attrptr != NULL); attrptr = ippNextAttribute(collection)) { if (strcmp("....", ippGetName(attrptr)) == 0) { ....TopMargin = ippGetInteger(attrptr, 0); } else if (strcmp("....", ippGetName(attrptr)) == 0) { ....BottomMargin = ippGetInteger(attrptr, 0); } else if (strcmp("....", ippGetName(attrptr)) == 0) { ....LeftMargin = ippGetInteger(attrptr, 0); } else if (strcmp("....", ippGetName(attrptr)) == 0) { ....RightMargin = ippGetInteger(attrptr, 0); } } .... } 

PVS-Studio चेतावनी: V560 CWE-571 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: (j <4)। ipphelper.c 926

ध्यान दें कि चर j का मान कहीं भी बढ़ा हुआ नहीं है। इसका अर्थ यह है कि उपसर्ग (j <4) हमेशा सत्य होता है।

हमेशा सही / गलत स्थितियों से संबंधित, पीवीएस-स्टूडियो विश्लेषक के उपयोगी संचालन की सबसे बड़ी संख्या उस कोड को संदर्भित करती है जहां ऑब्जेक्ट बनाने का परिणाम नए ऑपरेटर का उपयोग करके जांचा जाता है। दूसरे शब्दों में, विश्लेषक निम्नलिखित कोड पैटर्न का पता लगाता है:

 T *p = new T; if (p == nullptr) return ERROR; 

इस तरह की जाँच व्यर्थ है। यदि ऑब्जेक्ट के लिए मेमोरी आवंटित करना संभव नहीं था, तो std :: bad_alloc प्रकार का एक अपवाद फेंका जाता है, और यह पॉइंटर मान के चेक में नहीं आया।

नोट। नया ऑपरेटर नया (std :: nothrow) T लिखकर अशक्त लौट सकता है । हालाँकि, यह चर्चा की गई त्रुटियों पर लागू नहीं होता है। पीवीएस-स्टूडियो विश्लेषक ध्यान में रखता है (std :: nothrow) और इस तरह से ऑब्जेक्ट बनाए जाने पर चेतावनी नहीं देता है।

ऐसा लग सकता है कि ऐसी त्रुटियां हानिरहित हैं। ठीक है, इसके बारे में सोचो, एक अतिरिक्त जांच जो कभी काम नहीं करती है। वैसे भी, एक अपवाद को फेंक दिया जाएगा जो कहीं न कहीं संसाधित किया जाएगा। दुर्भाग्य से, कुछ डेवलपर्स स्टेटमेंट-इफ-सच में रखते हैं यदि स्टेटमेंट एक्शन जो संसाधनों को मुक्त करते हैं, आदि चूंकि यह कोड निष्पादित नहीं कर रहा है, इसलिए यह मेमोरी लीक और अन्य त्रुटियों को जन्म दे सकता है।

इन मामलों में से एक पर विचार करें जो मैंने एंड्रॉइड कोड में देखा था।

 int parse_apk(const char *path, const char *target_package_name) { .... FileMap *dataMap = zip->createEntryFileMap(entry); if (dataMap == NULL) { ALOGW("%s: failed to create FileMap\n", __FUNCTION__); return -1; } char *buf = new char[uncompLen]; if (NULL == buf) { ALOGW("%s: failed to allocate %" PRIu32 " byte\n", __FUNCTION__, uncompLen); delete dataMap; return -1; } .... } 

PVS-Studio चेतावनी: V668 CWE-570 'बूफ़' पॉइंटर को अशक्त करने के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। स्कैन 21pp 21pp

कृपया ध्यान दें कि यदि दूसरा मेमोरी ब्लॉक आवंटित करना संभव नहीं है, तो प्रोग्रामर पहले ब्लॉक को खाली करने की कोशिश करता है:

 delete dataMap; 

इस कोड को कभी भी नियंत्रण नहीं मिलेगा। यह मृत कोड है। यदि कोई अपवाद होता है, तो स्मृति रिसाव हो सकता है।

ऐसा कोड लिखना मौलिक रूप से गलत है। ऐसे मामलों के लिए स्मार्ट पॉइंटर्स का आविष्कार किया गया था।

कुल मिलाकर, पीवीएस-स्टूडियो विश्लेषक ने एंड्रॉइड कोड में 176 स्थानों का पता लगाया जहां नए का उपयोग करके ऑब्जेक्ट बनाने के बाद सूचक की जांच की जाती है। मुझे समझ नहीं आया कि इन स्थानों में से प्रत्येक कितना खतरनाक है, और निश्चित रूप से, मैं इन सभी चेतावनियों के साथ लेख को अव्यवस्थित नहीं करूंगा। रुचि रखने वाले लोग Android_V668.txt फ़ाइल में अन्य चेतावनी देख सकते हैं।

एक अशक्त सूचक को संदर्भित करना

अशक्त सूचक को हटाने से अपरिभाषित कार्यक्रम व्यवहार होता है, इसलिए ऐसे स्थानों को ढूंढना और उन्हें ठीक करना उपयोगी है। स्थिति के आधार पर, पीवीएस-स्टूडियो विश्लेषक सामान्य कमजोरी गणना के अनुसार इन त्रुटियों को वर्गीकृत कर सकते हैं:

• CWE-119 : मेमोरी बफ़र की सीमा के भीतर संचालन का अनुचित प्रतिबंध
• CWE-476 : NULL Pointer Dereference
• CWE-628 : गलत तरीके से निर्दिष्ट तर्क के साथ फ़ंक्शन कॉल
• सीडब्ल्यूई -690 : अनलिमिटेड रिटर्न वैल्यू टू नाउल पॉइंटर डेरेफेरेंस

मुझे अक्सर गैर-मानक या गलत स्थितियों को संभालने के लिए जिम्मेदार कोड में ऐसी त्रुटियां मिलती हैं। कोई भी ऐसे कोड का परीक्षण नहीं करता है, और त्रुटि बहुत लंबे समय तक इसमें रह सकती है। बस ऐसे मामले पर अब विचार किया जाएगा।

 bool parseEffect(....) { .... if (xmlProxyLib == nullptr) { ALOGE("effectProxy must contain a <%s>: %s", tag, dump(*xmlProxyLib)); return false; } .... } 

PVS-Studio चेतावनी: V522 CWE-476 अशक्त सूचक 'xmlProxyLib' की डेरेफेरिंग हो सकती है। EffectConfig.cpp 205

यदि xmlProxyLib पॉइंटर nullptr है , तो प्रोग्रामर एक डिबग संदेश प्रदर्शित करता है, जिसके लिए इस पॉइंटर को डीरेल करना आवश्यक है। उफ़ ...

अब त्रुटि के एक और अधिक दिलचस्प संस्करण पर विचार करें।

 static void soinfo_unload_impl(soinfo* root) { .... soinfo* needed = find_library(si->get_primary_namespace(), library_name, RTLD_NOLOAD, nullptr, nullptr); if (needed != nullptr) { // <= PRINT("warning: couldn't find %s needed by %s on unload.", library_name, si->get_realpath()); return; } else if (local_unload_list.contains(needed)) { return; } else if (needed->is_linked() && // <= needed->get_local_group_root() != root) { external_unload_list.push_back(needed); } else { unload_list.push_front(needed); } .... } 

PVS-Studio चेतावनी: V522 CWE-476 नल पॉइंटर की आवश्यकता 'जगह ले सकता है'। linker.cpp 1847

यदि पॉइंटर की जरूरत है! = Nullptr , तो एक चेतावनी जारी की जाती है, जो कार्यक्रम का एक बहुत ही संदिग्ध व्यवहार है। यह अंत में स्पष्ट हो जाता है कि कोड में एक त्रुटि है यदि आप नीचे देखते हैं और देखते हैं कि जरूरत के साथ == nullptr , null सूचक को आवश्यक अभिव्यक्ति में dereferenced जाएगा-> is_linked () ।

सबसे अधिक संभावना है, ऑपरेटरों! = और == बस यहाँ उलझन में हैं। यदि आप प्रतिस्थापित करते हैं, तो फ़ंक्शन कोड समझ में आता है, और त्रुटि गायब हो जाती है।

अशक्त पॉइंटर के संभावित डेरेफेरिंग के बारे में चेतावनी का बड़ा हिस्सा फॉर्म की स्थिति को संदर्भित करता है:

 T *p = (T *) malloc (N); *p = x; 

यदि मैलोड नहीं किया जा सकता है , तो कार्य जैसे कि मॉलॉक , स्ट्रैडअप, और NULL वापस आ सकते हैं। इसलिए, आप पॉइंटर को चेक किए बिना इन कार्यों को वापस करने वाले बिंदुओं को नहीं कर सकते।

कई समान त्रुटियां हैं, इसलिए मैं केवल दो सरल कोड टुकड़े दूंगा: पहला वाला
माल्डोक और स्ट्रैपअप के साथ दूसरा।

 DownmixerBufferProvider::DownmixerBufferProvider(....) { .... effect_param_t * const param = (effect_param_t *) malloc(downmixParamSize); param->psize = sizeof(downmix_params_t); .... } 

PVS-Studio चेतावनी: V522 CWE-690 एक संभावित नल पॉइंटर 'परम' की ड्रीफरिंग हो सकती है। चेक लाइनें: 245, 244. बफ़रप्रोवाइडर्स.सीपी 245

 static char* descriptorClassToDot(const char* str) { .... newStr = strdup(lastSlash); newStr[strlen(lastSlash)-1] = '\0'; .... } 

PVS-Studio चेतावनी: V522 CWE-690 एक संभावित नल पॉइंटर 'न्यूस्ट्रीम' की dereferencing हो सकती है। चेक लाइनें: 203, 202. DexDump.cpp 203

कोई कह सकता है कि ये मामूली त्रुटियां हैं। यदि पर्याप्त मेमोरी नहीं है, तो नल पॉइंटर को डेरेफेर करने पर प्रोग्राम बस दुर्घटनाग्रस्त हो जाएगा, और यह सामान्य है। चूंकि कोई मेमोरी नहीं है, इसलिए इस स्थिति को किसी तरह संभालने की कोशिश करने के लिए कुछ भी नहीं है।

ऐसा व्यक्ति गलत है। पॉइंटर्स की जाँच होनी चाहिए! मैंने इस विषय पर लेख में विस्तार से जांच की " मालॉक फ़ंक्शन क्या लौटा है यह जांचना महत्वपूर्ण है "। मैं अत्यधिक अनुशंसा करता हूं कि आप इसे उन सभी को पढ़ें जिन्होंने इसे नहीं पढ़ा है।

संक्षेप में, खतरा यह है कि स्मृति को लिखना शून्य पते के पास जरूरी नहीं हो सकता है। डेटा को बहुत दूर कहीं एक मेमोरी पेज में लिखना संभव है जो राइट-प्रोटेक्टेड नहीं है, और इस तरह एक मायावी त्रुटि का कारण बनता है, या सामान्य तौर पर इस त्रुटि का उपयोग भेद्यता के रूप में किया जा सकता है। आइए देखें कि check_size फ़ंक्शन के उदाहरण से मेरा क्या मतलब है।

 int check_size(radio_metadata_buffer_t **metadata_ptr, const uint32_t size_int) { .... metadata = realloc(metadata, new_size_int * sizeof(uint32_t)); memmove( (uint32_t *)metadata + new_size_int - (metadata->count + 1), (uint32_t *)metadata + metadata->size_int - (metadata->count + 1), (metadata->count + 1) * sizeof(uint32_t)); .... } 

पीवीएस-स्टूडियो चेतावनी: V769 CWE-119 द '(uint32_t *) मेटाडेटा' पॉइंटर इन '(uint32_t *) मेटाडेटा + new_size_int' अभिव्यक्ति शून्य हो सकती है। ऐसे मामले में, परिणामस्वरूप मूल्य संवेदनहीन होगा और इसका उपयोग नहीं किया जाना चाहिए। चेक लाइनें: 91, 89. Radio_metadata.c 91

मैंने फ़ंक्शन के तर्क को नहीं समझा, लेकिन यह आवश्यक नहीं है। मुख्य बात यह है कि एक नया बफर बनाया जाता है और डेटा को वहां कॉपी किया जाता है। यदि realloc फ़ंक्शन NULL देता है , तो डेटा को पता ((uint32_t *) NULL + मेटाडेटा-> size_int - (मेटाडेटा-> काउंट + 1)) में कॉपी किया जाएगा।

यदि मेटाडेटा-> size_int मान बड़ा है, तो परिणाम पछतावा होगा। यह पता चला है कि डेटा स्मृति के यादृच्छिक टुकड़े को लिखा गया है।

वैसे, एक अन्य प्रकार की अशक्त सूचक डफरिंग है, जिसे पीवीएस-स्टूडियो विश्लेषक सीडब्ल्यूई -690 के रूप में नहीं, बल्कि सीडब्ल्यूई -628 (अमान्य तर्क) के रूप में वर्गीकृत करता है।

 static void parse_tcp_ports(const char *portstring, uint16_t *ports) { char *buffer; char *cp; buffer = strdup(portstring); if ((cp = strchr(buffer, ':')) == NULL) .... } 

PVS-Studio चेतावनी: V575 CWE-628 संभावित अशक्त सूचक 'strchr' फ़ंक्शन में दिया गया है। पहले तर्क का निरीक्षण करें। जाँच लाइनें: 47, 46. libxt_tcp.c 47

तथ्य यह है कि स्ट्रैचर फ़ंक्शन को कॉल करने पर पॉइंटर डेरेफ़रिंग होगा। इसलिए, विश्लेषक इस स्थिति की व्याख्या फ़ंक्शन के गलत मान को पारित करने के रूप में करता है।

इस प्रकार की शेष 194 चेतावनियाँ मैं Android_V522_V575.txt फ़ाइल में सूचीबद्ध करता हूँ ।

वैसे, नए ऑपरेटर को कॉल करने के बाद पॉइंटर की जांच करने के बारे में पहले से चर्चा की गई चेतावनियों द्वारा इन सभी त्रुटियों के लिए एक विशेष पवित्रता प्रदान की जाती है। यह पता चला है कि मॉलोक / रियललॉक / स्ट्रैडअप फ़ंक्शन के लिए 195 कॉल हैं , और इसी तरह, जब सूचक की जांच नहीं की जाती है। लेकिन 176 ऐसे स्थान हैं जहां पर नए को कॉल करने के बाद पॉइंटर को चेक किया जाता है। सहमत हूँ, एक अजीब दृष्टिकोण!

अंत में, यह हमारे लिए चेतावनी V595 और V1004 पर विचार करने के लिए बनी हुई है, जो कि अशक्त लोगों के उपयोग से भी जुड़ी हैं।

V595 उन स्थितियों का पता लगाता है जहाँ पॉइंटर को डिफर किया जाता है और फिर जाँच की जाती है। सिंथेटिक उदाहरण:

 p->foo(); if (!p) Error(); 

V1004 रिवर्स स्थिति का पता चलता है जब सूचक को पहले चेक किया गया था, और फिर इसे करना भूल गया। सिंथेटिक उदाहरण:

 if (p) p->foo(); p->doo(); 

आइए एंड्रॉइड कोड के कुछ अंशों को देखें, जहां इस प्रकार की त्रुटियां थीं। विशेष रूप से समझाएं कि उनकी विशेषताओं की आवश्यकता नहीं है।

 PV_STATUS RC_UpdateBuffer(VideoEncData *video, Int currLayer, Int num_skip) { rateControl *rc = video->rc[currLayer]; MultiPass *pMP = video->pMP[currLayer]; if (video == NULL || rc == NULL || pMP == NULL) return PV_FAIL; .... } 

PVS-Studio चेतावनी: V595 CWE-476 'वीडियो' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 385, 388. rate_control.cpp 385

 static void resampler_reset(struct resampler_itfe *resampler) { struct resampler *rsmp = (struct resampler *)resampler; rsmp->frames_in = 0; rsmp->frames_rq = 0; if (rsmp != NULL && rsmp->speex_resampler != NULL) { speex_resampler_reset_mem(rsmp->speex_resampler); } } 

PVS-Studio चेतावनी: V595 CWE-476 'rsmp' पॉइंटर को nullrr के खिलाफ सत्यापित करने से पहले उपयोग किया गया था। चेक लाइनें: 54, 57. resampler.c 54

 void bta_gattc_disc_cmpl(tBTA_GATTC_CLCB* p_clcb, UNUSED_ATTR tBTA_GATTC_DATA* p_data) { .... if (p_clcb->status != GATT_SUCCESS) { if (p_clcb->p_srcb) { std::vector<tBTA_GATTC_SERVICE>().swap( p_clcb->p_srcb->srvc_cache); } bta_gattc_cache_reset(p_clcb->p_srcb->server_bda); } .... } 

पीवीएस-स्टूडियो चेतावनी: V1004 CWE-476 'p_clcb-> p_srcb' पॉइंटर का उपयोग अशक्त रूप से उपयोग किए जाने के बाद किया गया था क्योंकि इसे nullptr के खिलाफ सत्यापित किया गया था। चेक लाइनें: 695, 701. bta_gattc_act.cc 701

इस प्रकार की अन्य चेतावनियों पर विचार करना दिलचस्प नहीं है। उनमें त्रुटियां और गलत चेतावनी दोनों हैं जो खराब या मुश्किल से लिखे गए कोड के कारण उत्पन्न होती हैं।

मैंने एक दर्जन उपयोगी चेतावनियाँ लिखी हैं:

• V1004 CWE-476 The 'ain' pointer was used unsafely after it was verified against nullptr. Check lines: 101, 105. rsCpuIntrinsicBLAS.cpp 105
• V595 CWE-476 The 'outError' pointer was utilized before it was verified against nullptr. Check lines: 437, 450. Command.cpp 437
• V595 CWE-476 The 'out_last_reference' pointer was utilized before it was verified against nullptr. Check lines: 432, 436. AssetManager2.cpp 432
• V595 CWE-476 The 'set' pointer was utilized before it was verified against nullptr. Check lines: 4524, 4529. ResourceTypes.cpp 4524
• V595 CWE-476 The 'reply' pointer was utilized before it was verified against nullptr. Check lines: 126, 133. Binder.cpp 126
• V595 CWE-476 The 'video' pointer was utilized before it was verified against nullptr. Check lines: 532, 540. rate_control.cpp 532
• V595 CWE-476 The 'video' pointer was utilized before it was verified against nullptr. Check lines: 702, 711. rate_control.cpp 702
• V595 CWE-476 The 'pInfo' pointer was utilized before it was verified against nullptr. Check lines: 251, 254. ResolveInfo.cpp 251
• V595 CWE-476 The 'address' pointer was utilized before it was verified against nullptr. Check lines: 53, 55. DeviceHalHidl.cpp 53
• V595 CWE-476 The 'halAddress' pointer was utilized before it was verified against nullptr. Check lines: 55, 82. DeviceHalHidl.cpp 55

और फिर मैं ऊब गया, और मैंने इस प्रकार की चेतावनी को फ़िल्टर किया। इसलिए, मुझे यह भी पता नहीं है कि विश्लेषक ने कितनी वास्तविक त्रुटियों का पता लगाया है। ये चेतावनी उनके नायक की प्रतीक्षा कर रहे हैं, जो सावधानीपूर्वक उनका अध्ययन करेंगे और कोड में बदलाव करेंगे।

मैं इस तरह की त्रुटियों के लिए अपने नए पाठकों का ध्यान आकर्षित करना चाहता हूं:

 NJ_EXTERN NJ_INT16 njx_search_word(NJ_CLASS *iwnn, ....) { .... NJ_PREVIOUS_SELECTION_INFO *prev_info = &(iwnn->previous_selection); if (iwnn == NULL) { return NJ_SET_ERR_VAL(NJ_FUNC_NJ_SEARCH_WORD, NJ_ERR_PARAM_ENV_NULL); } .... } 

PVS-Studio चेतावनी: V595 CWE-476 'iwnn' पॉइंटर को nullptr के खिलाफ सत्यापित करने से पहले उपयोग किया गया था। चेक लाइनें: 686, 689. ndapi.c 686

कुछ लोगों को लगता है कि यहां कोई त्रुटि नहीं है, क्योंकि "पॉइंटर का कोई वास्तविक संबंध नहीं है।" एक नहीं चर का पता बस गणना की है। इसके अलावा, यदि सूचक iwnn शून्य है, तो फ़ंक्शन बाहर निकल जाएगा। इसलिए, कुछ भी बुरा नहीं हुआ कि हमने पहले एक वर्ग के सदस्य के पते की गलत गणना की थी।

नहीं, आप ऐसी बात नहीं कर सकते। यह कोड अपरिभाषित व्यवहार की ओर ले जाता है, और इसलिए इसे लिखा नहीं जा सकता है। अपरिभाषित व्यवहार स्वयं को प्रकट कर सकता है, उदाहरण के लिए, निम्नानुसार:

1. कंपाइलर पॉइंटर को देखते हुए डिरेल्ड करता है: iwnn-> past_selection
2. आप एक अशक्त सूचक को निष्क्रिय नहीं कर सकते, क्योंकि यह अपरिभाषित व्यवहार है
3. संकलक निष्कर्ष निकालता है कि इवन सूचक हमेशा गैर-शून्य होता है
4. संकलक अतिरिक्त जाँच को हटा देता है: यदि (iwnn == NULL)
5. यही है, अब जब प्रोग्राम निष्पादित किया जाता है, तो नल पॉइंटर के लिए चेक का प्रदर्शन नहीं किया जाता है, और क्लास के सदस्य को गलत पॉइंटर से काम शुरू होता है

इस विषय को मेरे लेख में अधिक विस्तार से वर्णित किया गया है " एक अशक्त सूचक को निष्क्रिय करने से अपरिभाषित व्यवहार होता है ।"

निजी डेटा को स्मृति में मिटाया नहीं जाता है

एक गंभीर प्रकार की संभावित भेद्यता पर विचार करें, जिसे CWE-14 के रूप में कॉमन वेकनेस एन्यूमरेशन के अनुसार वर्गीकृत किया गया है : क्लीयर बफ़र्स को कोड का कंपाइलर रिमूवल।

संक्षेप में, लब्बोलुआब यह है: कंपाइलर को मेमसेट फ़ंक्शन कॉल को हटाने का अधिकार है यदि उसके बाद बफर का उपयोग नहीं किया जाता है।

जब मैं इस प्रकार की भेद्यता के बारे में लिखता हूं, तो टिप्पणियां आवश्यक रूप से प्रकट होती हैं कि यह संकलक में एक गड़बड़ है जिसे ठीक करने की आवश्यकता है। नहीं, यह कोई गड़बड़ नहीं है। और आपत्ति करने से पहले, कृपया निम्नलिखित सामग्री पढ़ें:

• रोमन फोमिचव। निजी डेटा को सुरक्षित रूप से साफ़ करें ।
• सामान्य कमजोरी संलयन। CWE-14 ।
• V597 निदान का विवरण ।

सामान्य तौर पर, सब कुछ गंभीर है। क्या Android में ऐसी कोई त्रुटियां हैं? जरूर है। वे आम तौर पर कई हैं जहां प्रमाण हैं: प्रमाण :)।

आइए एंड्रॉइड कोड पर वापस जाएं और FwdLockGlue_InitializeRoundKeys फ़ंक्शन की शुरुआत और अंत देखें , क्योंकि मध्य हमारे लिए दिलचस्प नहीं है।

 static void FwdLockGlue_InitializeRoundKeys() { unsigned char keyEncryptionKey[KEY_SIZE]; .... memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data. } 

PVS-Studio चेतावनी: V597 CWE-14 संकलक 'मेमसेट' फ़ंक्शन कॉल को हटा सकता है, जिसका उपयोग 'keyEncryptionKey' बफर को फ्लश करने के लिए किया जाता है। निजी डेटा को मिटाने के लिए memset_s () फ़ंक्शन का उपयोग किया जाना चाहिए। FwdLockGlue.c 102 keyEnc एन्क्रिप्शनKey

सरणी ढेर पर बनाई गई है और निजी जानकारी संग्रहीत करती है। फ़ंक्शन के अंत में, वे इस सरणी को शून्य से भरना चाहते हैं ताकि यह गलती से न हो जाए जहां यह नहीं होना चाहिए। यह जानकारी कैसे प्राप्त की जा सकती है जहां यह नहीं होना चाहिए, लेख " स्मृति को अधिलेखित करें - क्यों? " बताएगा । शून्य के साथ निजी जानकारी के साथ एक सरणी भरने के लिए, मेमसेट फ़ंक्शन का उपयोग किया जाता है । टिप्पणी "शून्य महत्वपूर्ण डेटा" पुष्टि करता है कि हम सब कुछ सही ढंग से समझते हैं।



परेशानी यह है कि बहुत अधिक संभावना के साथ कंपाइलर रिलीज़ संस्करण बनाते समय मेमसेट फ़ंक्शन कॉल को हटा देगा । चूंकि मेमसेट कॉल के बाद बफर का उपयोग नहीं किया जाता है, इसलिए कंपाइलर के दृष्टिकोण से, मेमसेट फ़ंक्शन का कॉल अपने आप में शानदार है।

अधिक 10 चेतावनी मैं एक फ़ाइल में लिखा था Android_V597.txt ।

एक और त्रुटि थी जहां मेमोरी ओवरराइट नहीं की गई थी, हालांकि इस मामले में मेमसेट फ़ंक्शन का इससे कोई लेना-देना नहीं है।

 void SHA1Transform(uint32_t state[5], const uint8_t buffer[64]) { uint32_t a, b, c, d, e; .... /* Wipe variables */ a = b = c = d = e = 0; } 

PVS-Studio चेतावनी: V1001 CWE-563 'a' वेरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया जाता है। sha1.c 213

PVS-Studio ने इस तथ्य से संबंधित एक विसंगति का पता लगाया कि चर को मान देने के बाद, उनका उपयोग नहीं किया जाता है। विश्लेषक ने इस दोष को CWE-563 के रूप में वर्गीकृत किया : उपयोग के बिना चर के लिए असाइनमेंट। और, औपचारिक रूप से, वह सही है, हालांकि, वास्तव में, यहां हम फिर से सीडब्ल्यूई -14 के साथ काम कर रहे हैं। संकलक इन असाइनमेंट को फेंक देगा, क्योंकि सी और सी ++ के दृष्टिकोण से वे बहुत ही कम हैं। नतीजतन, स्टैक वैरिएबल ए , बी , सी , डी और ई के पुराने मूल्यों को बनाए रखेगा , जो निजी डेटा को स्टोर करते हैं।

अनिर्दिष्ट / कार्यान्वयन-परिभाषित व्यवहार

जब आप थके हुए नहीं होते हैं, तो एक जटिल मामले को देखते हैं, जिसके लिए मेरे हिस्से पर गहन विवरण की आवश्यकता होगी।

 typedef int32_t GGLfixed; GGLfixed gglFastDivx(GGLfixed n, GGLfixed d) { if ((d>>24) && ((d>>24)+1)) { n >>= 8; d >>= 8; } return gglMulx(n, gglRecip(d)); } 

पीवीएस-स्टूडियो चेतावनी: V793 यह अजीब है कि '(d >> 24) + 1' कथन का परिणाम स्थिति का एक हिस्सा है। शायद, इस कथन की तुलना किसी और चीज़ से की जानी चाहिए थी। फिक्स्ड

। सीपीसी 75 प्रोग्रामर यह जांचना चाहता था कि वेरिएबल डी के 8 हाई-ऑर्डर बिट्स में यूनिट्स हैं, लेकिन सभी बिट्स एक साथ नहीं। दूसरे शब्दों में, प्रोग्रामर यह सत्यापित करना चाहता था कि 0x00 और 0xFF के अलावा कोई भी मूल्य उच्च बाइट में है।

उन्होंने अनावश्यक रूप से रचनात्मक रूप से इस समस्या के समाधान के लिए संपर्क किया। शुरू करने के लिए, उन्होंने सत्यापित किया कि सबसे महत्वपूर्ण बिट्स एक अभिव्यक्ति लिखकर नॉनजरो हैं (डी >> 24)। इस अभिव्यक्ति के दावे हैं, लेकिन अभिव्यक्ति के दाईं ओर पार्स करना अधिक दिलचस्प है: ((डी >> 24) +1)। प्रोग्रामर उच्च आठ बिट्स को निम्न बाइट में स्थानांतरित करता है। उसी समय, यह गणना करता है कि सबसे महत्वपूर्ण साइन बिट अन्य सभी बिट्स में डुप्लिकेट है। यानीअगर वैरिएबल d 0b11111111'00000000'00000000'00000000 है, तो बदलाव के बाद हमें 0b11111111'11111111'11111111'11111111 मान मिलता है। प्रकार के इंट के 0xFFFFFFFF के मान में 1 जोड़कर , प्रोग्रामर को 0 प्राप्त करने की योजना है। यह है: -1 + 1 = 0। इस प्रकार, अभिव्यक्ति का उपयोग करते हुए ((डी >> 24) +1), वह जांचता है कि सभी उच्च आठ बिट्स 1 के बराबर नहीं हैं। मैं समझता हूं कि यह काफी कठिन है, इसलिए कृपया जल्दी मत करो और यह पता लगाने की कोशिश करें कि कैसे और क्या काम करता है :)।

अब देखते हैं कि इस कोड में क्या गलत है।

शिफ्ट करते समय, सबसे महत्वपूर्ण संकेत बिट "स्मियर" आवश्यक नहीं है। यहाँ मानक इसके बारे में क्या कहता है: “E1 >> E2 का मूल्य E1 सही स्थान पर स्थानांतरित E2 सा स्थान है। यदि E1 में एक अहस्ताक्षरित प्रकार है या यदि E1 में एक हस्ताक्षरित प्रकार और एक गैर-नकारात्मक मूल्य है, तो परिणाम का मान E1 / 2 ^ E2 के भागफल का अभिन्न अंग है। यदि E1 में एक हस्ताक्षरित प्रकार और एक नकारात्मक मूल्य है, तो परिणामी मूल्य कार्यान्वयन-परिभाषित है। "

नवीनतम प्रस्ताव हमारे लिए महत्वपूर्ण है। इसलिए, हम कार्यान्वयन-परिभाषित व्यवहार से मिले। यह कोड कैसे काम करेगा यह माइक्रोप्रोसेसर आर्किटेक्चर और कंपाइलर कार्यान्वयन पर निर्भर करता है। पारी के बाद, शून्य सबसे महत्वपूर्ण बिट्स में अच्छी तरह से दिखाई दे सकते हैं, और फिर अभिव्यक्ति ((डी >> 24) +1) हमेशा 0 से अलग होगी, अर्थात। हमेशा सही मूल्य होगा।

इसलिए निष्कर्ष: बुद्धिमान होने की जरूरत नहीं है। यदि आप लिखते हैं, तो कोड अधिक विश्वसनीय और समझने योग्य बन जाएगा, उदाहरण के लिए:

 GGLfixed gglFastDivx(GGLfixed n, GGLfixed d) { uint32_t hibits = static_cast<uint32_t>(d) >> 24; if (hibits != 0x00 && hibits != 0xFF) { n >>= 8; d >>= 8; } return gglMulx(n, gglRecip(d)); } 

शायद, मैंने सुझाव दिया कि आदर्श विकल्प नहीं है, लेकिन इस कोड में कार्यान्वयन द्वारा परिभाषित कोई व्यवहार नहीं है, और पाठक के लिए यह समझना आसान होगा कि क्या जाँच की जा रही है।

आप एक कप कॉफी या चाय के लायक हैं। विचलित करें, और जारी रखें: हम अनिर्दिष्ट व्यवहार के एक दिलचस्प मामले की प्रतीक्षा कर रहे हैं।

साक्षात्कार में, आवेदक को पहले प्रश्नों में से एक के रूप में, मैं निम्नलिखित पूछता हूं: " प्रिंटफ फ़ंक्शन क्या प्रिंट करेगा और क्यों?"

 int i = 5; printf("%d,%d", i++, i++) 

सही उत्तर: यह अनिर्दिष्ट व्यवहार है। फ़ंक्शन को कॉल करते समय वास्तविक तर्कों की गणना करने की प्रक्रिया को परिभाषित नहीं किया गया है। कभी-कभी, मैं यह भी प्रदर्शित करता हूं कि विज़ुअल सी ++ की मदद से संकलित यह कोड स्क्रीन पर "6.5" प्रदर्शित करता है, जो नए लोगों को भ्रमित करता है जो ज्ञान और आत्मा में पूर्ण ठहराव के लिए कमजोर हैं :)।

यह एक दूरगामी समस्या की तरह लग सकता है। लेकिन नहीं, यह कोड गंभीर अनुप्रयोगों में पाया जा सकता है, उदाहरण के लिए, एंड्रॉइड कोड में।

 bool ComposerClient::CommandReader::parseSetLayerCursorPosition( uint16_t length) { if (length != CommandWriterBase::kSetLayerCursorPositionLength) { return false; } auto err = mHal.setLayerCursorPosition(mDisplay, mLayer, readSigned(), readSigned()); if (err != Error::NONE) { mWriter.setError(getCommandLoc(), err); } return true; } 

PVS-Studio चेतावनी: V681 CWE-758 भाषा मानक एक आदेश को परिभाषित नहीं करता है जिसमें तर्कों के मूल्यांकन के दौरान 'रीडसाइनड' कार्यों को बुलाया जाएगा। ComposerClient.cpp 836

हम कोड की इस पंक्ति में रुचि रखते हैं:

 mHal.setLayerCursorPosition(...., readSigned(), readSigned()); 

रीड किए गए फ़ंक्शन को कॉल करके, दो मान पढ़े जाते हैं। लेकिन यह अनुमान लगाना असंभव है कि मूल्यों को किस क्रम में पढ़ा जाएगा। यह अनिर्दिष्ट व्यवहार का एक क्लासिक मामला है।

एक स्थिर कोड विश्लेषक का उपयोग करने के लाभ

यह पूरा लेख सामान्य रूप से स्थिर कोड विश्लेषण और विशेष रूप से हमारे पीवीएस-स्टूडियो टूल को लोकप्रिय बनाता है। हालाँकि, कुछ त्रुटियाँ स्थिर विश्लेषण की संभावनाओं को प्रदर्शित करने के लिए एकदम सही हैं। उन्हें कोड समीक्षाओं द्वारा पहचानना मुश्किल है, और केवल एक गैर-थका हुआ कार्यक्रम आसानी से उन्हें नोटिस करता है। ऐसे कुछ मामलों पर विचार करें।

 const std::map<std::string, int32_t> kBootReasonMap = { .... {"watchdog_sdi_apps_reset", 106}, {"smpl", 107}, {"oem_modem_failed_to_powerup", 108}, {"reboot_normal", 109}, {"oem_lpass_cfg", 110}, // <= {"oem_xpu_ns_error", 111}, // <= {"power_key_press", 112}, {"hardware_reset", 113}, {"reboot_by_powerkey", 114}, {"reboot_verity", 115}, {"oem_rpm_undef_error", 116}, {"oem_crash_on_the_lk", 117}, {"oem_rpm_reset", 118}, {"oem_lpass_cfg", 119}, // <= {"oem_xpu_ns_error", 120}, // <= {"factory_cable", 121}, {"oem_ar6320_failed_to_powerup", 122}, {"watchdog_rpm_bite", 123}, {"power_on_cable", 124}, {"reboot_unknown", 125}, .... }; 

पीवीएस-स्टूडियो चेतावनी:

• V766 CWE-462 एक ही कुंजी '"oem_lpass_cfg" के साथ एक आइटम पहले ही जोड़ा जा चुका है। bootstat.cpp 264
• V766 CWE-462 एक ही कुंजी '"oem_xpu_ns_error" के साथ एक आइटम पहले ही जोड़ा जा चुका है। bootstat.cpp 265

समान कुंजियों वाले विभिन्न मानों को क्रमबद्ध साहचर्य कंटेनर ( std :: map ) में डाला जाता है। कॉमन वीकनेस एन्यूमरेशन के संदर्भ में, यह CWE-462 : एसोसिएटिव लिस्ट में डुप्लिकेट की है।

कार्यक्रम का पाठ छोटा किया जाता है और त्रुटियों को टिप्पणियों के साथ चिह्नित किया जाता है, इसलिए त्रुटि स्पष्ट लगती है, लेकिन जब आप इस कोड को अपनी आंखों से पढ़ते हैं, तो ऐसी त्रुटियों को ढूंढना बहुत मुश्किल है।

कोड के एक और टुकड़े पर विचार करें, जिसे पढ़ना बहुत मुश्किल है, क्योंकि यह एक ही प्रकार और निर्बाध है।

 MtpResponseCode MyMtpDatabase::getDevicePropertyValue(....) { .... switch (type) { case MTP_TYPE_INT8: packet.putInt8(longValue); break; case MTP_TYPE_UINT8: packet.putUInt8(longValue); break; case MTP_TYPE_INT16: packet.putInt16(longValue); break; case MTP_TYPE_UINT16: packet.putUInt16(longValue); break; case MTP_TYPE_INT32: packet.putInt32(longValue); break; case MTP_TYPE_UINT32: packet.putUInt32(longValue); break; case MTP_TYPE_INT64: packet.putInt64(longValue); break; case MTP_TYPE_UINT64: packet.putUInt64(longValue); break; case MTP_TYPE_INT128: packet.putInt128(longValue); break; case MTP_TYPE_UINT128: packet.putInt128(longValue); // <= break; .... } 

PVS-Studio चेतावनी: V525 CWE-682 कोड में समान ब्लॉकों का संग्रह है। आइटम 'putInt8', 'putUInt8', 'putInt16', 'putUInt16', 'putInt32', 'putUInt32', 'putInt64', 'putUInt64', 'putInt128', 'putInt128' को लाइनों 620, 623, 626, 629, 629 , 632, 635, 638, 641, 644, 647 android_mtp_MtpDatabase.cpp 620

तो MTP_TYPE_UINT128 समारोह की वजह से किया जा सकता था putUInt128 , नहीं putInt128 ।

और इस खंड में अंतिम असफल कॉपी-पेस्ट का एक बड़ा उदाहरण है।

 static void btif_rc_upstreams_evt(....) { .... case AVRC_PDU_REQUEST_CONTINUATION_RSP: { BTIF_TRACE_EVENT( "%s() REQUEST CONTINUATION: target_pdu: 0x%02d", __func__, pavrc_cmd->continu.target_pdu); tAVRC_RESPONSE avrc_rsp; if (p_dev->rc_connected == TRUE) { memset(&(avrc_rsp.continu), 0, sizeof(tAVRC_NEXT_RSP)); avrc_rsp.continu.opcode = opcode_from_pdu(AVRC_PDU_REQUEST_CONTINUATION_RSP); avrc_rsp.continu.pdu = AVRC_PDU_REQUEST_CONTINUATION_RSP; avrc_rsp.continu.status = AVRC_STS_NO_ERROR; avrc_rsp.continu.target_pdu = pavrc_cmd->continu.target_pdu; send_metamsg_rsp(p_dev, -1, label, ctype, &avrc_rsp); } } break; case AVRC_PDU_ABORT_CONTINUATION_RSP: { BTIF_TRACE_EVENT( "%s() ABORT CONTINUATION: target_pdu: 0x%02d", __func__, pavrc_cmd->abort.target_pdu); tAVRC_RESPONSE avrc_rsp; if (p_dev->rc_connected == TRUE) { memset(&(avrc_rsp.abort), 0, sizeof(tAVRC_NEXT_RSP)); avrc_rsp.abort.opcode = opcode_from_pdu(AVRC_PDU_ABORT_CONTINUATION_RSP); avrc_rsp.abort.pdu = AVRC_PDU_ABORT_CONTINUATION_RSP; avrc_rsp.abort.status = AVRC_STS_NO_ERROR; avrc_rsp.abort.target_pdu = pavrc_cmd->continu.target_pdu; send_metamsg_rsp(p_dev, -1, label, ctype, &avrc_rsp); } } break; .... } 

विश्लेषक की चेतावनी और आगे के पाठ को पढ़ने से पहले, मैं सुझाव देता हूं कि स्वयं त्रुटि की तलाश करें।

ताकि आप गलती से जवाब को तुरंत न पढ़ लें, यहाँ ध्यान आकर्षित करने के लिए आपके लिए एक तस्वीर है। यदि आप रुचि रखते हैं कि शिलालेख जावा के साथ एक अंडा का क्या मतलब है, तो यहां आप हैं ।

इसलिए, मुझे आशा है कि आपने टाइपोस की खोज का आनंद लिया है। अब विश्लेषक को चेतावनी देने का समय है: V778 CWE-682 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'निरंतर' के बजाय 'गर्भपात' चर का उपयोग किया जाना चाहिए। btif_rc.cc 1554

जाहिर है, कॉपी-पेस्ट विधि का उपयोग करके कोड लिखा गया था, और एक व्यक्ति, हमेशा की तरह, कॉपी किए गए कोड के टुकड़े को संपादित करने की प्रक्रिया में चौकस नहीं हो सकता था। नतीजतन, बहुत अंत में, उन्होंने " निरंतर " को " गर्भपात " से प्रतिस्थापित नहीं किया ।

यानी दूसरे ब्लॉक में लिखा जाना चाहिए:

 avrc_rsp.abort.target_pdu = pavrc_cmd->abort.target_pdu; 

यह स्थिति पूरी तरह से " अंतिम पंक्ति प्रभाव " की परिभाषा के तहत आती है , क्योंकि नामों को बदलने की गलती अंत में की गई थी।

facepalm

एक बहुत ही मजेदार बग छोटे-एंडियन और बड़े-एंडियन डेटा प्रारूपों के बीच रूपांतरण से संबंधित है ( बाइट क्रम देखें )।

 inline uint32_t bswap32(uint32_t pData) { return (((pData & 0xFF000000) >> 24) | ((pData & 0x00FF0000) >> 8) | ((pData & 0x0000FF00) << 8) | ((pData & 0x000000FF) << 24)); } bool ELFAttribute::merge(....) { .... uint32_t subsection_length = *reinterpret_cast<const uint32_t*>(subsection_data); if (llvm::sys::IsLittleEndianHost != m_Config.targets().isLittleEndian()) bswap32(subsection_length); .... } 

PVS-Studio चेतावनी: V530 CWE-252 फ़ंक्शन 'bswap32' के वापसी मूल्य का उपयोग करने की आवश्यकता है। ELFAttribute.cpp 84 bswap32

फ़ंक्शन के बारे में कोई शिकायत नहीं है । लेकिन इसका उपयोग गलत तरीके से किया जाता है:

 bswap32(subsection_length); 

लेखक ने सुझाव दिया कि चर को संदर्भ द्वारा फ़ंक्शन में पास किया जाता है और वहां बदल दिया जाता है। हालाँकि, आपको फ़ंक्शन द्वारा दिए गए मान का उपयोग करना चाहिए। नतीजतन, कोई डेटा रूपांतरण नहीं होता है।

विश्लेषक ने इस त्रुटि को CWE-252 : अनियंत्रित वापसी मूल्य के रूप में पहचाना । लेकिन, वास्तव में, सीडब्ल्यूई -198 : गलत बाइट ऑर्डर का उपयोग यहां कॉल करना अधिक उपयुक्त है। दुर्भाग्य से, विश्लेषक यह नहीं समझ सकता है कि उच्च-स्तरीय बिंदु से त्रुटि क्या है। हालांकि, यह उसे कोड में इस गंभीर दोष की पहचान करने से नहीं रोकता है।

सही कोड है:

 subsection_length = bswap32(subsection_length); 

एंड्रॉइड कोड में एक ही त्रुटि के साथ तीन और स्थान हैं:

• V530 CWE-252 'bswap32' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। ELFAttribute.cpp 218
• V530 CWE-252 'bswap32' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। ELFAttribute.cpp 346
• V530 CWE-252 'bswap32' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। ELFAttribute.cpp 352

ऐसी त्रुटियों से बचने के लिए, [[नोडोडकार्ड]] विशेषता का उपयोग करने की सिफारिश की जाती है । यह विशेषता यह इंगित करने के लिए उपयोग की जाती है कि किसी फ़ंक्शन के रिटर्न मान का उपयोग किया जाना चाहिए। इसलिए, यदि आप इस तरह लिखते हैं:

 [[nodiscard]] inline uint32_t bswap32(uint32_t pData) { ... } 

तब फ़ाइल को संकलित करने के चरण में भी त्रुटि का पता लगाया जाएगा। आप मेरे सहयोगी के लेख " C ++ 17 " से कुछ नई उपयोगी विशेषताओं के बारे में अधिक जान सकते हैं ।

अगम्य कोड

प्रोग्रामिंग और कंपाइलर सिद्धांत में, पहुंच योग्य कोड प्रोग्राम कोड का हिस्सा है जिसे किसी भी परिस्थिति में निष्पादित नहीं किया जा सकता है, क्योंकि यह नियंत्रण प्रवाह ग्राफ में पहुंच से बाहर है।

कॉमन वीकनेस एन्यूमरेशन के दृष्टिकोण से, यह CWE-561 : डेड कोड है।

 virtual sp<IEffect> createEffect(....) { .... if (pDesc == NULL) { return effect; if (status != NULL) { *status = BAD_VALUE; } } .... } 

पीवीएस-स्टूडियो चेतावनी: V779 CWE-561 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। IAudioFlinger.cpp 733

ऑपरेटर वापसी स्पष्ट रूप से नीचे स्थित होना चाहिए।

इस प्रकार की अन्य त्रुटियां:

• V779 CWE-561 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। bta_hf_client_main.cc 612
• V779 CWE-561 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। android_media_ImageReader.cpp 468
• V779 CWE-561 अनुपयोगी कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। AMPEG4AudioAssembler.cpp 187

ब्रेक

स्विच के अंदर भूल गए ब्रेक सी और सी ++ प्रोग्रामर की एक क्लासिक गलती है। इसका मुकाबला करने के लिए, C ++ 17 में [[परित्याग]] के रूप में एक उपयोगी एनोटेशन दिखाई दिया । आप इस त्रुटि और [[गिरावट]] के बारे में मेरे लेख " ब्रेक एंड इर्रिथ " में अधिक पढ़ सकते हैं । लेकिन जब दुनिया पुराने कोड से भरी होती है, जहां [[परती]] का उपयोग नहीं किया जाता है, तो पीवीएस-स्टूडियो आपके लिए उपयोगी है। Android में पाए जाने वाले कुछ बगों पर विचार करें। कॉमन वीकनेस एन्यूमरेशन के अनुसार, इन त्रुटियों को CWE-484 : ओकेड ब्रेक स्टेटमेंट इन स्विच के रूप में वर्गीकृत किया गया है।

 bool A2dpCodecConfigLdac::setCodecConfig(....) { .... case BTAV_A2DP_CODEC_SAMPLE_RATE_192000: if (sampleRate & A2DP_LDAC_SAMPLING_FREQ_192000) { result_config_cie.sampleRate = A2DP_LDAC_SAMPLING_FREQ_192000; codec_capability_.sample_rate = codec_user_config_.sample_rate; codec_config_.sample_rate = codec_user_config_.sample_rate; } case BTAV_A2DP_CODEC_SAMPLE_RATE_16000: case BTAV_A2DP_CODEC_SAMPLE_RATE_24000: case BTAV_A2DP_CODEC_SAMPLE_RATE_NONE: codec_capability_.sample_rate = BTAV_A2DP_CODEC_SAMPLE_RATE_NONE; codec_config_.sample_rate = BTAV_A2DP_CODEC_SAMPLE_RATE_NONE; break; .... } 

PVS-Studio चेतावनी: V796 CWE-484 यह संभव है कि स्विच स्टेटमेंट में 'ब्रेक' स्टेटमेंट गायब है। a2dp_vendor_ldac.cc 912

मुझे लगता है कि त्रुटि के स्पष्टीकरण की आवश्यकता नहीं है। मैं केवल इस बात पर ध्यान देता हूं कि अक्सर कोड में एक विसंगति का एक से अधिक तरीकों से पता लगाया जाता है। उदाहरण के लिए, V519 चेतावनियों द्वारा भी इस त्रुटि का पता लगाया जाता है:

• V519 CWE-563 'codec_capability_.sample_rate' चर क्रमिक रूप से दो बार मान असाइन किया गया है। शायद यह एक गलती है। चेक लाइनें: 910, 916. a2dp_vendor_ldac.cc 916
• V519 CWE-563 'codec_config_.sample_rate' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 911, 917. a2dp_vendor_ldac.cc 917

और कुछ और त्रुटियाँ:

 Return<void> EffectsFactory::getAllDescriptors(....) { .... switch (status) { case -ENOSYS: { // Effect list has changed. goto restart; } case -ENOENT: { // No more effects available. result.resize(i); } default: { result.resize(0); retval = Result::NOT_INITIALIZED; } } .... } 

PVS-Studio चेतावनी: V796 CWE-484 यह संभव है कि स्विच स्टेटमेंट में 'ब्रेक' स्टेटमेंट गायब है। EffectFactory.cpp 118

 int Reverb_getParameter(....) { .... case REVERB_PARAM_REFLECTIONS_LEVEL: *(uint16_t *)pValue = 0; case REVERB_PARAM_REFLECTIONS_DELAY: *(uint32_t *)pValue = 0; case REVERB_PARAM_REVERB_DELAY: *(uint32_t *)pValue = 0; break; .... } 

PVS-Studio चेतावनी: V796 CWE-484 यह संभव है कि स्विच स्टेटमेंट में 'ब्रेक' स्टेटमेंट गायब है। EffectReverb.cpp 1847

 static SLresult IAndroidConfiguration_GetConfiguration(....) { .... switch (IObjectToObjectID((thiz)->mThis)) { case SL_OBJECTID_AUDIORECORDER: result = android_audioRecorder_getConfig( (CAudioRecorder *) thiz->mThis, configKey, pValueSize, pConfigValue); break; case SL_OBJECTID_AUDIOPLAYER: result = android_audioPlayer_getConfig( (CAudioPlayer *) thiz->mThis, configKey, pValueSize, pConfigValue); default: result = SL_RESULT_FEATURE_UNSUPPORTED; break; } .... } 

PVS-Studio चेतावनी: V796 CWE-484 यह संभव है कि स्विच स्टेटमेंट में 'ब्रेक' स्टेटमेंट गायब है। IAndroidConfiguration.cpp 90

गलत स्मृति प्रबंधन

यहां मैंने गलत मेमोरी प्रबंधन से संबंधित त्रुटियों को संकलित किया है। इस तरह की चेतावनियाँ, सामान्य कमजोरी गणना के अनुसार, निम्नानुसार वर्गीकृत की जाती हैं:

• CWE-401 : अंतिम संदर्भ को हटाने से पहले मेमोरी की अनुचित रिलीज ('मेमोरी लीक')
• CWE-562 : रिटर्न ऑफ स्टैक वेरिएबल एड्रेस
• CWE-762 : बेमेल मेमोरी मैनेजमेंट रूटीन

आइए उन कार्यों से शुरू करें जो पहले से ही नष्ट हो चुके चर का संदर्भ देते हैं।

 TransformIterator& operator++(int) { TransformIterator tmp(*this); ++*this; return tmp; } TransformIterator& operator--(int) { TransformIterator tmp(*this); --*this; return tmp; } 

पीवीएस-स्टूडियो चेतावनी:

• V558 CWE-562 फ़ंक्शन अस्थायी स्थानीय ऑब्जेक्ट का संदर्भ देता है: tmp। transform_iterator.h 77
• V558 CWE-562 फ़ंक्शन अस्थायी स्थानीय ऑब्जेक्ट का संदर्भ देता है: tmp। transform_iterator.h 92

जब फ़ंक्शन अपने निष्पादन को पूरा करते हैं, तो tmp वेरिएबल नष्ट हो जाता है, क्योंकि यह स्टैक पर बनाया गया था। नतीजतन, फ़ंक्शन एक पहले से ही नष्ट हो चुके (नॉनटेन्सेन्ट) ऑब्जेक्ट का संदर्भ देते हैं।

इसका सही मान लौटना होगा:

 TransformIterator operator++(int) { TransformIterator tmp(*this); ++*this; return tmp; } TransformIterator operator--(int) { TransformIterator tmp(*this); --*this; return tmp; } 

और भी अधिक दुखद कोड पर विचार करें जो घनिष्ठ ध्यान देने योग्य हो।

 int register_socket_transport( int s, const char* serial, int port, int local) { atransport* t = new atransport(); if (!serial) { char buf[32]; snprintf(buf, sizeof(buf), "T-%p", t); serial = buf; } .... } 

PVS-Studio चेतावनी: V507 CWE-562 सूचक स्थानीय सरणी 'buf' को इस सरणी के दायरे से बाहर संग्रहीत किया जाता है। ऐसा पॉइंटर अवैध हो जाएगा। transport.cpp 1030

यह एक खतरनाक कोड है। यदि सीरियल तर्क का वास्तविक मूल्य NULL है, तो स्टैक पर एक अस्थायी बफर का उपयोग किया जाना चाहिए। जब इफ स्टेटमेंट समाप्त होता है, तो बफ़ एरे मौजूद रहता है। जिस स्थान पर बफर बनाया गया था, उसका उपयोग स्टैक पर बनाए गए अन्य चर को संग्रहीत करने के लिए किया जा सकता है। डेटा में एक नारकीय गड़बड़ी शुरू हो जाएगी, और इस तरह की त्रुटि के परिणामों की भविष्यवाणी की जाती है।

निम्नलिखित त्रुटियां वस्तुओं को बनाने और नष्ट करने के लिए असंगत तरीकों से संबंधित हैं।

 void SensorService::SensorEventConnection::reAllocateCacheLocked(....) { sensors_event_t *eventCache_new; const int new_cache_size = computeMaxCacheSizeLocked(); eventCache_new = new sensors_event_t[new_cache_size]; .... delete mEventCache; mEventCache = eventCache_new; mCacheSize += count; mMaxCacheSize = new_cache_size; } 

पीवीएस-स्टूडियो चेतावनी: वी 611 सीडब्ल्यूई -762 'नई टी []' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी, लेकिन 'डिलीट' ऑपरेटर का उपयोग करके जारी किया गया था। इस कोड का निरीक्षण करने पर विचार करें। शायद 'डिलीट [] mEventCache?' का उपयोग करना बेहतर है। जाँच लाइनें: 391, 384. SensorEventConnection.cpp 391

यहाँ सब कुछ सरल है। MEventCache वर्ग के एक सदस्य द्वारा इंगित बफर को नए [] ऑपरेटर का उपयोग करके आवंटित किया गया है । और डिलीट ऑपरेटर का उपयोग करके इस मेमोरी को फ्री करें । यह गलत है और अपरिभाषित कार्यक्रम व्यवहार की ओर ले जाता है।

इसी तरह की त्रुटि:

 aaudio_result_t AAudioServiceEndpointCapture::open(....) { .... delete mDistributionBuffer; int distributionBufferSizeBytes = getStreamInternal()->getFramesPerBurst() * getStreamInternal()->getBytesPerFrame(); mDistributionBuffer = new uint8_t[distributionBufferSizeBytes]; .... } 

पीवीएस-स्टूडियो चेतावनी: वी 611 सीडब्ल्यूई -762 'नई टी []' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी, लेकिन 'डिलीट' ऑपरेटर का उपयोग करके जारी किया गया था। इस कोड का निरीक्षण करने पर विचार करें। शायद 'डिलीट [] mDistributionBuffer;' का उपयोग करना बेहतर है। AAudioServiceEndpointCapture.cpp 50

मुझे लगता है कि त्रुटि के लिए किसी स्पष्टीकरण की आवश्यकता नहीं है।

निम्नलिखित मामला थोड़ा अधिक दिलचस्प है, लेकिन त्रुटि का सार बिल्कुल समान है।

 struct HeifFrameInfo { .... void set(....) { .... mIccData.reset(new uint8_t[iccSize]); .... } .... std::unique_ptr<uint8_t> mIccData; }; 

V554 CWE-762 unique_ptr का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा।HeifDecoderAPI.h 62

डिफ़ॉल्ट रूप से, स्मार्ट पॉइंटर क्लास std :: unique_ptr किसी ऑब्जेक्ट को नष्ट करने के लिए डिलीट ऑपरेटर को कॉल करता है । हालाँकि, सेट फ़ंक्शन में, नए [] ऑपरेटर का उपयोग करके मेमोरी आवंटित की जाती है ।

सही विकल्प:

 std::unique_ptr<uint8_t[]> mIccData; 

अन्य त्रुटियां:

• V554 CWE-762 unique_ptr का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा। atrace.cpp 949
• V554 CWE-762 unique_ptr का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा। atrace.cpp 950
• V554 CWE-762 unique_ptr का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा। HeifDecoderImpl.cpp 102
• V554 CWE-762 unique_ptr का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा। HeifDecoderImpl.cpp 166
• V554 CWE-762 unique_ptr का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा। ColorSpace.cpp 360

मेमोरी लीक त्रुटियां इस अनुभाग को पूरा करेंगी। एक अप्रिय आश्चर्य यह है कि ऐसी 20 से अधिक त्रुटियां थीं। मुझे ऐसा लगता है कि ये बहुत दर्दनाक दोष हो सकते हैं, जिससे ऑपरेटिंग सिस्टम के लंबे समय तक निरंतर संचालन के दौरान मुक्त स्मृति में धीरे-धीरे कमी हो सकती है।

 Asset* Asset::createFromUncompressedMap(FileMap* dataMap, AccessMode mode) { _FileAsset* pAsset; status_t result; pAsset = new _FileAsset; result = pAsset->openChunk(dataMap); if (result != NO_ERROR) return NULL; pAsset->mAccessMode = mode; return pAsset; } 

PVS-Studio चेतावनी: V773 CWE-401 समारोह 'पेससेट' पॉइंटर जारी किए बिना बाहर किया गया था। एक स्मृति रिसाव संभव है।Asset.cpp 296

यदि एक निश्चित हिस्सा खोलना संभव नहीं था, तो फ़ंक्शन ऑब्जेक्ट को नष्ट किए बिना बाहर निकलता है, पॉइंटरसेट चर में संग्रहीत पॉइंटर को इंगित करता है । नतीजतन, एक स्मृति रिसाव हो जाएगा।

अन्य त्रुटियां समान हैं, इसलिए मुझे लेख में उन पर विचार करने का कोई कारण नहीं दिखता है। रुचि रखने वाले लोग फ़ाइल में अन्य चेतावनी देख सकते हैं: Android_V773.txt ।

एक सरणी में विदेश जा रहे हैं

बड़ी संख्या में गलत पैटर्न हैं जो सरणी के अतिप्रवाह की ओर ले जाते हैं। Android के मामले में, मुझे निम्न प्रकार के केवल एक त्रुटि पैटर्न का पता चला:

 if (i < 0 || i > MAX) return; A[i] = x; 

सी और सी ++ में, सरणी कोशिकाओं को 0 से गिना जाता है, इसलिए सरणी में एक तत्व का अधिकतम सूचकांक स्वयं सरणी के आकार से कम होना चाहिए। सही जाँच इस तरह होनी चाहिए:

 if (i < 0 || i >= MAX) return; A[i] = x; 

आम कमजोरी एन्यूमरेशन के अनुसार, एक सरणी को ओवरफ्लो करते हुए , सीडब्ल्यूई -119 : एक मेमोरी बफ़र की सीमा के भीतर संचालन के अनुचित प्रतिबंध के रूप में वर्गीकृत किया गया है ।

एंड्रॉइड कोड में इन त्रुटियों को कैसे देखें, इस पर एक नज़र डालें।

 static btif_hf_cb_t btif_hf_cb[BTA_AG_MAX_NUM_CLIENTS]; static bool IsSlcConnected(RawAddress* bd_addr) { if (!bd_addr) { LOG(WARNING) << __func__ << ": bd_addr is null"; return false; } int idx = btif_hf_idx_by_bdaddr(bd_addr); if (idx < 0 || idx > BTA_AG_MAX_NUM_CLIENTS) { LOG(WARNING) << __func__ << ": invalid index " << idx << " for " << *bd_addr; return false; } return btif_hf_cb[idx].state == BTHF_CONNECTION_STATE_SLC_CONNECTED; } 

PVS-Studio चेतावनी: V557 CWE-119 ऐरे ओवररन संभव है। 'Idx' इंडेक्स का मान 6. btif_hf.cc पर पहुंच सकता है 277

सही चेक विकल्प:

 if (idx < 0 || idx >= BTA_AG_MAX_NUM_CLIENTS) { 

वास्तव में एक ही त्रुटियों में दो और चीजें पाई गईं:

• V557 CWE-119 ऐरे ओवररन संभव है। 'Idx' इंडेक्स का मान 6. btif_hf.cc 869 तक पहुंच सकता है
• V557 CWE-119 ऐरे ओवररन संभव है। 'अनुक्रमणिका' सूचकांक का मान 6. btif_rc.cc 374 तक पहुंच सकता है

टूटे हुए चक्र

एक खराबी चक्र लिखने के कई तरीके हैं। एंड्रॉइड कोड में, मैंने उन त्रुटियों को पूरा किया, जो सामान्य कमजोरी गणना के अनुसार वर्गीकृत की जा सकती हैं:

• CWE-20 : अनुचित इनपुट सत्यापन
• CWE-670 : हमेशा-गलत नियंत्रण प्रवाह कार्यान्वयन
• CWE-691 : अपर्याप्त नियंत्रण प्रवाह प्रबंधन
• CWE-834 : अत्यधिक Iteration

उसी समय, निश्चित रूप से, साइकिल लिखते समय "अपने पैर को गोली मार" करने के अन्य तरीके हैं, लेकिन इस बार वे मुझसे नहीं मिले।

 int main(int argc, char **argv) { .... char c; printf("%s is already in *.base_fs format, just ..... ", ....); rewind(blk_alloc_file); while ((c = fgetc(blk_alloc_file)) != EOF) { fputc(c, base_fs_file); } .... } 

PVS-Studio चेतावनी: V739 CWE-20 EOF की तुलना 'चार' प्रकार के मान से नहीं की जानी चाहिए। '(C = fgetc (blk_alloc_file))' 'int' प्रकार का होना चाहिए। 61 blk_alloc_to_base_fs.c

विश्लेषक ने पाया कि लगातार EOF प्रकार का एक चर की तुलना में है चार । आइए देखें कि यह कोड गलत क्यों है।

समारोह fgetc रिटर्न एक पूर्णांक , अर्थात्, यह एक संख्या 0 से 255 या EOF (-1) पर लौट सकते हैं। पुराना मान प्रकार के एक चर में संग्रहीत है चार । इस वजह से, 0xFF (255) के मान वाला वर्ण -1 हो जाता है और इसकी व्याख्या उसी तरह की जाती है जैसे किसी फ़ाइल (EOF) के अंत में होती है।

इस तरह की त्रुटियों के कारण, विस्तारित एएससीआईआई कोड का उपयोग करने वाले उपयोगकर्ता कभी-कभी ऐसी स्थिति का सामना करते हैं, जहां उनकी वर्णमाला में से एक वर्ण प्रोग्राम द्वारा गलत तरीके से संसाधित होता है। उदाहरण के लिए, Windows-1251 में एन्कोड किए गए रूसी वर्णमाला के अंतिम अक्षर में कोड 0xFF है और इसे कुछ कार्यक्रमों द्वारा फाइल के अंत के रूप में माना जाता है।

सारांशित करते हुए, हम कह सकते हैं कि चक्र को रोकने की शर्त गलत लिखी गई है। स्थिति को ठीक करने के लिए, चर c प्रकार का होना चाहिए ।

हम जारी रखने और बयान के लिए उपयोग करते समय अधिक परिचित त्रुटियों पर विचार करते हैं ।

 status_t AudioPolicyManager::registerPolicyMixes(....) { .... for (size_t i = 0; i < mixes.size(); i++) { .... for (size_t j = 0; i < mHwModules.size(); j++) { // <= if (strcmp(AUDIO_HARDWARE_MODULE_ID_REMOTE_SUBMIX, mHwModules[j]->mName) == 0 && mHwModules[j]->mHandle != 0) { rSubmixModule = mHwModules[j]; break; } .... } .... } 

PVS-Studio चेतावनी: V534 CWE-691 यह संभावना है कि 'के लिए' ऑपरेटर के अंदर एक गलत चर की तुलना की जा रही है। 'I' की समीक्षा करने पर विचार करें। AudioPolicyManager.cpp 2489

नेस्टेड लूप में टाइपो के कारण, स्थिति चर i का उपयोग करती है , हालांकि आपको चर j का उपयोग करना होगा । नतीजतन, चर जम्मू अनियंत्रित रूप से बढ़ा हुआ है, जो समय के साथ mHwModules सरणी को सीमा से बाहर ले जाएगा । आगे क्या होगा इसकी भविष्यवाणी करना असंभव है, क्योंकि अपरिभाषित कार्यक्रम व्यवहार होगा।

वैसे, एक त्रुटि वाला यह टुकड़ा पूरी तरह से दूसरे फ़ंक्शन में कॉपी किया गया था। इसलिए, विश्लेषक को यहां ठीक वही त्रुटि मिली: AudioPolicyManager.cpp 2586।

3 और कोड स्निपेट हैं जो मेरे लिए बहुत संदिग्ध हैं। हालाँकि, मैं यह नहीं कहना चाहता कि यह कोड निश्चित रूप से गलत है, क्योंकि वहाँ जटिल तर्क है। किसी भी मामले में, मुझे इस कोड पर ध्यान देना चाहिए ताकि लेखक इसकी जांच करे।

पहला टुकड़ा:

 void ce_t3t_handle_check_cmd(....) { .... for (i = 0; i < p_cb->cur_cmd.num_blocks; i++) { .... for (i = 0; i < T3T_MSG_NDEF_ATTR_INFO_SIZE; i++) { checksum += p_temp[i]; } .... } .... } 

PVS-Studio चेतावनी: V535 CWE-691 चर 'i' का उपयोग इस लूप के लिए और बाहरी लूप के लिए किया जा रहा है। चेक लाइनें: 398, 452. Ce_t3t.cc 452

ध्यान दें कि बाहरी और आंतरिक दोनों चक्रों के लिए चर का उपयोग किया जाता है।

दो और समान विश्लेषक ट्रिगर:

• V535 CWE-691 चर 'xx' का उपयोग इस लूप के लिए और बाहरी लूप के लिए किया जा रहा है। चेक लाइनें: 801, 807. sdp_db.cc 807
• V535 CWE-691 चर 'xx' का उपयोग इस लूप के लिए और बाहरी लूप के लिए किया जा रहा है। चेक लाइनें: 424, 438. nfa_hci_act.cc 438

क्या तुम अभी तक नहीं थके हो? मैं आपके प्रोजेक्ट की जांच करने के लिए पीवीएस-स्टूडियो को रोकने और डाउनलोड करने का सुझाव देता हूं ।

अब हम जारी रखते हैं।

 #define NFA_HCI_LAST_PROP_GATE 0xFF tNFA_HCI_DYN_GATE* nfa_hciu_alloc_gate(uint8_t gate_id, tNFA_HANDLE app_handle) { .... for (gate_id = NFA_HCI_FIRST_HOST_SPECIFIC_GENERIC_GATE; gate_id <= NFA_HCI_LAST_PROP_GATE; gate_id++) { if (gate_id == NFA_HCI_CONNECTIVITY_GATE) gate_id++; if (nfa_hciu_find_gate_by_gid(gate_id) == NULL) break; } if (gate_id > NFA_HCI_LAST_PROP_GATE) { LOG(ERROR) << StringPrintf( "nfa_hci_alloc_gate - no free Gate ID: %u " "App Handle: 0x%04x", gate_id, app_handle); return (NULL); } .... } 

पीवीएस-स्टूडियो चेतावनी: V654 CWE-834 लूप की स्थिति 'गेट_िड <= 0xFF' हमेशा सही होती है। nfa_hci_utils.cc 248

निम्नलिखित पर ध्यान दें:

• निरंतर NFA_HCI_LAST_PROP_GATE 0xFF के बराबर है।
• प्रकार uint8_t के एक चर का उपयोग लूप काउंटर के रूप में किया जाता है । इसलिए, इस चर का मान सीमा [0..0xFF] है।

यह पता चला है कि हालत गेट_आईडी <= NFA_HCI_LAST_PROP_GATE हमेशा सत्य है और लूप के निष्पादन को रोक नहीं सकती है।

विश्लेषक ने इस त्रुटि को CWE-834 के रूप में वर्गीकृत किया, लेकिन इसकी व्याख्या CWE-571 के रूप में भी की जा सकती है: अभिव्यक्ति हमेशा सच होती है।

लूप में अगली त्रुटि अपरिभाषित व्यवहार से संबंधित है।

 status_t SimpleDecodingSource::doRead(....) { .... for (int retries = 0; ++retries; ) { .... } 

PVS-Studio चेतावनी: V654 CWE-834 लूप की स्थिति '++ रिट्रीज़' हमेशा सही होती है। SimpleDecodingSource.cpp 226

जाहिर है, डेवलपर चर करना चाहता था पुनर्प्रयास चर के लिए सभी संभव मूल्यों ले लिया है पूर्णांक और उसके बाद ही चक्र समाप्त हो गया है।

लूप बंद हो जाना चाहिए जब अभिव्यक्ति ++ रीट्रीज़ 0. है और यह केवल तभी संभव है जब वेरिएबल ओवरफ्लो होता है। चूंकि चर हस्ताक्षरित प्रकार का है, इसलिए इसका अतिप्रवाह अपरिभाषित व्यवहार की ओर जाता है। इसलिए, यह कोड गलत है और इससे अप्रत्याशित परिणाम हो सकते हैं। उदाहरण के लिए, कंपाइलर को चेक हटाने और काउंटर बढ़ाने के लिए केवल निर्देश छोड़ने का पूरा अधिकार है।

और इस खंड में आखिरी गलती।

 status_t Check(const std::string& source) { .... int pass = 1; .... do { .... switch(rc) { case 0: SLOGI("Filesystem check completed OK"); return 0; case 2: SLOGE("Filesystem check failed (not a FAT filesystem)"); errno = ENODATA; return -1; case 4: if (pass++ <= 3) { SLOGW("Filesystem modified - rechecking (pass %d)", pass); continue; // <= } SLOGE("Failing check after too many rechecks"); errno = EIO; return -1; case 8: SLOGE("Filesystem check failed (no filesystem)"); errno = ENODATA; return -1; default: SLOGE("Filesystem check failed (unknown exit code %d)", rc); errno = EIO; return -1; } } while (0); // <= return 0; } 

PVS-Studio चेतावनी: V696 CWE-670 'जारी रखें' ऑपरेटर 'do {...} को समाप्त करेगा (जबकि FALSE) लूप क्योंकि हालत हमेशा झूठी है। लाइनों की जाँच करें: 105, 121. Vfat.cpp 105

हमारे सामने प्रपत्र का एक लूप है:

 do { .... if (x) continue; .... } while (0) 

दोहराया पुनरावृत्तियों को करने के लिए, प्रोग्रामर जारी स्टेटमेंट का उपयोग करता है । यह गलत है।जारी बयान तुरंत लूप को फिर से शुरू नहीं करता है, लेकिन स्थिति की जांच करने के लिए आगे बढ़ता है। चूंकि स्थिति हमेशा झूठी होती है, किसी भी स्थिति में चक्र को केवल एक बार निष्पादित किया जाएगा।

त्रुटि को ठीक करने के लिए, कोड को फिर से लिखा जा सकता है, उदाहरण के लिए, इस तरह:

 for (;;) { .... if (x) continue; .... break; } 

परिवर्तनशील पुन: असाइनमेंट

पिछली मूल्य का उपयोग करने से पहले एक चर में फिर से लिखना एक बहुत ही सामान्य गलती है। ज्यादातर, टाइपो या असफल कॉपी-पेस्ट के कारण ऐसी त्रुटियां होती हैं। कॉमन वीकनेस एन्यूमरेशन के अनुसार, ऐसी त्रुटियों को CWE-563 : वर्जन के बिना उपयोग के लिए असाइनमेंट के रूप में वर्गीकृत किया गया है । एंड्रॉइड में ऐसी त्रुटियों के बिना नहीं।

 status_t XMLNode::flatten_node(....) const { .... memset(&namespaceExt, 0, sizeof(namespaceExt)); if (mNamespacePrefix.size() > 0) { namespaceExt.prefix.index = htodl(strings.offsetForString(mNamespacePrefix)); } else { namespaceExt.prefix.index = htodl((uint32_t)-1); } namespaceExt.prefix.index = htodl(strings.offsetForString(mNamespacePrefix)); namespaceExt.uri.index = htodl(strings.offsetForString(mNamespaceUri)); .... } 

PVS-Studio चेतावनी: V519 CWE-563 'namespaceExt.prefix.index' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 1535, 1539. XMLNode.cpp 1539

त्रुटि के सार को उजागर करने के लिए, मैं एक छद्म कोड लिखूंगा:

 if (a > 0) X = 1; else X = 2; X = 1; 

शर्त के बावजूद, चर X (वर्तमान कोड में यह namepaceExt.prefix.index है ) को हमेशा एक मान दिया जाएगा।

 bool AudioFlinger::RecordThread::threadLoop() { .... size_t framesToRead = mBufferSize / mFrameSize; framesToRead = min(mRsmpInFramesOA - rear, mRsmpInFramesP2 / 2); .... } 

PVS-Studio चेतावनी: V519 CWE-563 'फ्रेमटाउडर' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 6341, 6342। थ्रेड्स। सीपीसी 6342

यह स्पष्ट नहीं है कि घोषणा करते समय चर को इनिशियलाइज़ करना क्यों आवश्यक था, यदि इसके बाद एक और मूल्य तुरंत लिखा जाता है। यहाँ कुछ गड़बड़ है।

 void SchedulingLatencyVisitorARM::VisitArrayGet(....) { .... if (index->IsConstant()) { last_visited_latency_ = kArmMemoryLoadLatency; } else { if (has_intermediate_address) { } else { last_visited_internal_latency_ += kArmIntegerOpLatency; } last_visited_internal_latency_ = kArmMemoryLoadLatency; } .... } 

PVS-Studio चेतावनी: V519 CWE-563 'last_visited_internal_latency_' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 680, 682. अनुसूचक_आर्म। 682

बहुत ही अजीब, अर्थहीन कोड। मैं सुझाव देता हूं कि यह लिखा जाना चाहिए:

 last_visited_internal_latency_ += kArmMemoryLoadLatency; 

और अंतिम त्रुटि, यह दर्शाता है कि कैसे विश्लेषक थकाऊ रूप से त्रुटियों को ढूंढता है जो कि सावधानीपूर्वक कोड समीक्षा के साथ भी सबसे अधिक छोड़े जाने की संभावना है।

 void multiprecision_fast_mod(uint32_t* c, uint32_t* a) { uint32_t U; uint32_t V; .... c[0] += U; V = c[0] < U; c[1] += V; V = c[1] < V; c[2] += V; // V = c[2] < V; // <= c[2] += U; // V = c[2] < U; // <= c[3] += V; V = c[3] < V; c[4] += V; V = c[4] < V; c[5] += V; V = c[5] < V; .... } 

PVS-Studio चेतावनी: V519 CWE-563 'V' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 307, 309. p_256_multpreaches.cc 309

कोड इतना "अपनी आँखें फाड़ दो" कि मैं इसे समझना नहीं चाहता। यह स्पष्ट रूप से दिखाई देता है: कोड में एक टाइपो है, जिसे मैंने टिप्पणियों के साथ हाइलाइट किया है।

अन्य कीड़े

बिखरी हुई त्रुटियां हैं जिनके लिए अलग-अलग अध्याय बनाने का कोई मतलब नहीं है। हालांकि, वे पहले की तरह ही दिलचस्प और कपटी हैं।

प्राथमिकता संचालन

 void TagMonitor::parseTagsToMonitor(String8 tagNames) { std::lock_guard<std::mutex> lock(mMonitorMutex); // Expand shorthands if (ssize_t idx = tagNames.find("3a") != -1) { ssize_t end = tagNames.find(",", idx); char* start = tagNames.lockBuffer(tagNames.size()); start[idx] = '\0'; .... } .... } 

PVS-Studio चेतावनी: V593 CWE-783 'ए = बी! = सी' प्रकार की अभिव्यक्ति की समीक्षा करने पर विचार करें। अभिव्यक्ति की गणना निम्न प्रकार से की जाती है: 'ए = (बी! = सी)'। TagMonitor.cpp 50

आम कमजोरी एन्यूमरेशन: CWE-783 : ऑपरेटर की वरीयता तर्क त्रुटि।

प्रोग्रामर ने निम्नलिखित कल्पना की। "3 ए" को प्रतिस्थापित किया जाता है और इस विकल्प की स्थिति को आइडियल चर के लिए लिखा जाता है। यदि सबस्ट्रिंग पाया जाता है (idx! = -1), तो कोड चलना शुरू हो जाता है, जो idx वेरिएबल के मान का उपयोग करता है ।

दुर्भाग्य से, प्रोग्रामर संचालन की प्राथमिकताओं के बारे में उलझन में है। वास्तव में, चेक इस तरह काम करता है:

 if (ssize_t idx = (tagNames.find("3a") != -1)) 

सबसे पहले, यह देखने के लिए जाँचता है कि क्या स्ट्रिंग में एक विकल्प "3a" है, और परिणाम गलत / सत्य आइडियल वैरिएबल में रखा गया है । नतीजतन, idx वेरिएबल का मान 0 या 1. होता है।

यदि स्थिति सही है ( idx वेरिएबल 1 है), तो id वेरिएबल का उपयोग करने वाले तर्क को निष्पादित करना शुरू कर देता है । हमेशा 1 के बराबर एक चर गलत प्रोग्राम व्यवहार को जन्म देगा।

यदि आप स्थिति से चर का आरंभीकरण करते हैं तो आप त्रुटि को ठीक कर सकते हैं:

 ssize_t idx = tagNames.find("3a"); if (idx != -1) 

C ++ 17 का नया संस्करण भी आपको लिखने की अनुमति देता है:

 if (ssize_t idx = tagNames.find("3a"); idx != -1) 

अवैध निर्माणकर्ता

 struct HearingDevice { .... HearingDevice() { HearingDevice(RawAddress::kEmpty, false); } .... }; 

PVS-Studio चेतावनी: V603 CWE-665 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। यदि आप कंस्ट्रक्टर को कॉल करना चाहते हैं, तो 'this-> HearingDevice :: HearingDevice (....)' का उपयोग करना चाहिए। Hear_aid.cc 176

आम कमजोरी गणना: CWE-665 : अनुचित शुरुआत ।

प्रोग्रामर को अक्सर गलत किया जाता है जब किसी ऑब्जेक्ट को इनिशियलाइज़ करने के लिए कंस्ट्रक्टर को स्पष्ट रूप से कॉल करने की कोशिश की जाती है। क्लास में दो कंस्ट्रक्टर हैं। स्रोत कोड के आकार को कम करने के लिए, प्रोग्रामर ने एक निर्माता को दूसरे से कॉल करने का फैसला किया। लेकिन यह कोड डेवलपर को क्या उम्मीद करता है, यह बिल्कुल नहीं है।

निम्नलिखित होता है। HearingDevice प्रकार का एक नया अनाम ऑब्जेक्ट बनाया जाता है और फिर नष्ट हो जाता है। नतीजतन, वर्ग क्षेत्र असिंचित रहते हैं।

त्रुटि को ठीक करने के लिए, आप प्रतिनिधि निर्माणकर्ता का उपयोग कर सकते हैं (यह सुविधा C ++ 11 में दिखाई दी)। सही कोड है:

 HearingDevice() : HearingDevice(RawAddress::kEmpty, false) { } 

फ़ंक्शन मान वापस नहीं करता है

 int NET_RecvFrom(int s, void *buf, int len, unsigned int flags, struct sockaddr *from, int *fromlen) { socklen_t socklen = *fromlen; BLOCKING_IO_RETURN_INT( s, recvfrom(s, buf, len, flags, from, &socklen) ); *fromlen = socklen; } 

PVS-Studio चेतावनी: V591 CWE-393 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। linux_close.cpp 139

आम कमजोरी गणना: CWE-393 : गलत स्थिति कोड की वापसी।

फ़ंक्शन एक यादृच्छिक मान लौटाएगा। इस तरह की एक और त्रुटि: V591 CWE-393 गैर-शून्य फ़ंक्शन को एक मान वापस करना चाहिए। linux_close.cpp 158

गलत संरचना आकार गणना

 int MtpFfsHandle::handleControlRequest(....) { .... struct mtp_device_status *st = reinterpret_cast<struct mtp_device_status*>(buf.data()); st->wLength = htole16(sizeof(st)); .... } 

PVS-Studio चेतावनी: V568 यह अजीब है कि 'sizeof ()' ऑपरेटर एक वर्ग के लिए सूचक के आकार का मूल्यांकन करता है, लेकिन 'st' वर्ग ऑब्जेक्ट का आकार नहीं। MtpFfsHandle.cpp 251

मुझे यकीन है कि वे संरचना के आकार को इंगित करना चाहते थे, न कि पॉइंटर के आकार को, वेवलेंथ के सदस्य चर में । फिर सही कोड इस तरह होना चाहिए:

 st->wLength = htole16(sizeof(*st)); 

इसी तरह के विश्लेषक प्रतिक्रियाएं:

• V568 यह विचित्र है कि 'sizeof ()' ऑपरेटर एक वर्ग के लिए पॉइंटर के आकार का मूल्यांकन करता है, लेकिन 'cacheinfo' क्लास ऑब्जेक्ट का आकार नहीं। NetlinkEvent.cpp 220
• V568 यह अजीब है कि 'sizeof ()' ऑपरेटर एक वर्ग के लिए सूचक के आकार का मूल्यांकन करता है, लेकिन 'पृष्ठ-> अगले' वर्ग ऑब्जेक्ट का आकार नहीं। linker_block_allocator.cpp 146
• V568 यह विचित्र है कि sizeof () ऑपरेटर का तर्क 'और session_id' अभिव्यक्ति है। संदर्भ- ril.c 1775

अर्थहीन सा ऑपरेशन

 #define EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR 0x00000001 #define EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR 0x00000002 #define EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR 0x00000004 EGLContext eglCreateContext(....) { .... case EGL_CONTEXT_FLAGS_KHR: if ((attrib_val | EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR) || (attrib_val | EGL_CONTEXT_OPENGL_FORWARD_C....) || (attrib_val | EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR)) { context_flags = attrib_val; } else { RETURN_ERROR(EGL_NO_CONTEXT,EGL_BAD_ATTRIBUTE); } .... } 

PVS-Studio चेतावनी: V617 CWE-480 स्थिति का निरीक्षण करने पर विचार करें। '0x00000001' का तर्क '|' बिटवाइज़ ऑपरेशन में एक गैर-शून्य मान होता है। egl.cpp 1329

आम कमजोरी गणना: CWE-480 : गलत ऑपरेटर का उपयोग।

रूप की एक अभिव्यक्ति (ए | १) || (ए | 2) || (ए | 4) कोई मतलब नहीं है, क्योंकि परिणाम हमेशा सच होगा। वास्तव में, आपको & ऑपरेटर का उपयोग करने की आवश्यकता है , और फिर कोड समझ में आता है:

 if ((attrib_val & EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR) || (attrib_val & EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR) || (attrib_val & EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR)) 

इसी तरह की त्रुटि: V617 CWE-480 स्थिति का निरीक्षण करने पर विचार करें। '0x00000001' का तर्क '|' बिटवाइज़ ऑपरेशन में एक गैर-शून्य मान होता है। egl.cpp 1338

गलत बिट शिफ्ट

 template <typename AddressType> struct RegsInfo { .... uint64_t saved_reg_map = 0; AddressType saved_regs[64]; .... inline AddressType* Save(uint32_t reg) { if (reg > sizeof(saved_regs) / sizeof(AddressType)) { abort(); } saved_reg_map |= 1 << reg; saved_regs[reg] = (*regs)[reg]; return &(*regs)[reg]; } .... } 

PVS-Studio चेतावनी: V629 CWE-190 '1 << reg' अभिव्यक्ति का निरीक्षण करने पर विचार करें। 64-बिट प्रकार के बाद के विस्तार के साथ 32-बिट मूल्य का बिट शिफ्टिंग। RegsInfo.h 47

कॉमन वेकनेस एन्यूमरेशन: CWE-190 : इंटेगर ओवरफ्लो या रैपराउंड। 1 << reg

की पारी के साथ , चर reg का मूल्य सीमा [0..63] में है। अभिव्यक्ति 2 के अलग-अलग डिग्री प्राप्त करने का कार्य करती है, 2 ^ 0 से शुरू होती है और 2 ^ 63 के साथ समाप्त होती है।

कोड काम नहीं करता है। तथ्य यह है कि संख्यात्मक शाब्दिक 1 में 32-बिट इंट प्रकार है । इसलिए, यह 1 ^ 31 से अधिक मूल्य प्राप्त करने के लिए काम नहीं करेगा। एक बड़े मूल्य के लिए बदलाव से चर का अतिप्रवाह होता है और अपरिभाषित व्यवहार का उद्भव होता है।

सही कोड है:

 saved_reg_map |= static_cast<uint64_t>(1) << reg; 

या:

 saved_reg_map |= 1ULL << reg; 

स्ट्रिंग्स की नकल खुद से की जाती है।

 void PCLmGenerator::writeJobTicket() { // Write JobTicket char inputBin[256]; char outputBin[256]; if (!m_pPCLmSSettings) { return; } getInputBinString(m_pPCLmSSettings->userInputBin, &inputBin[0]); getOutputBin(m_pPCLmSSettings->userOutputBin, &outputBin[0]); strcpy(inputBin, inputBin); strcpy(outputBin, outputBin); .... } 

पीवीएस-स्टूडियो चेतावनी:

• V549 CWE-688 'strcpy' फ़ंक्शन का पहला तर्क दूसरे तर्क के बराबर है। genPCLm.cpp 1181
• V549 CWE-688 'strcpy' फ़ंक्शन का पहला तर्क दूसरे तर्क के बराबर है। genPCLm.cpp 1182

कॉमन वीकनेस एन्यूमरेशन: सीडब्ल्यूई -688: के वर्गीकरण के अनुसार फंक्शन कॉल विथ अयोग्य वर्जन या रेगुलेशन के रूप में संदर्भ।

स्ट्रिंग्स किसी कारण से खुद के लिए कॉपी की जाती हैं। सबसे अधिक संभावना है, यहां कुछ टाइपो हैं।

एक uninitialized वैरिएबल का उपयोग करना

 void mca_set_cfg_by_tbl(....) { tMCA_DCB* p_dcb; const tL2CAP_FCR_OPTS* p_opt; tMCA_FCS_OPT fcs = MCA_FCS_NONE; if (p_tbl->tcid == MCA_CTRL_TCID) { p_opt = &mca_l2c_fcr_opts_def; } else { p_dcb = mca_dcb_by_hdl(p_tbl->cb_idx); if (p_dcb) { p_opt = &p_dcb->p_chnl_cfg->fcr_opt; fcs = p_dcb->p_chnl_cfg->fcs; } } memset(p_cfg, 0, sizeof(tL2CAP_CFG_INFO)); p_cfg->mtu_present = true; p_cfg->mtu = p_tbl->my_mtu; p_cfg->fcr_present = true; memcpy(&p_cfg->fcr, p_opt, sizeof(tL2CAP_FCR_OPTS)); // <= .... } 

PVS-Studio चेतावनी: V614 CWE-824 संभावित रूप से एकतरफा सूचक 'p_opt' का इस्तेमाल किया। 'मेमसीपी' फ़ंक्शन के दूसरे वास्तविक तर्क की जाँच करने पर विचार करें। mca_main.cc 252

कॉमन वेकनेस एन्यूमरेशन: CWE-824 : Uninitialized Pointer का एक्सेस।

यदि p_tbl-> tcid! = MCA_CTRL_TCID और p_dcb == nullptr , तो पॉइंटर p_opt अनइंस्टॉल रहेगा।

असिंचित चर का अजीब उपयोग

 struct timespec { __time_t tv_sec; /* Seconds. */ long int tv_nsec; /* Nanoseconds. */ }; static inline timespec NsToTimespec(int64_t ns) { timespec t; int32_t remainder; t.tv_sec = ns / kNanosPerSecond; remainder = ns % kNanosPerSecond; if (remainder < 0) { t.tv_nsec--; remainder += kNanosPerSecond; } t.tv_nsec = remainder; return t; } 

PVS-Studio चेतावनी: V614 CWE-457 Uninitialized चर 't.tv_nsec' का उपयोग किया गया। clock_ns.h 55

कॉमन वीकनेस एन्यूमरेशन: CWE-457 : अनइंस्टॉलिज्ड वेरिएबल का उपयोग।

चर t.tv_nsec को कम करने के समय , यह असिंचित है। चर को बाद में प्रारंभ किया गया है: t.tv_nsec = शेष; ।यहाँ कुछ स्पष्ट रूप से भ्रमित है।

अभिव्यक्ति पर

 void bta_dm_co_ble_io_req(....) { .... *p_auth_req = bte_appl_cfg.ble_auth_req | (bte_appl_cfg.ble_auth_req & 0x04) | ((*p_auth_req) & 0x04); .... } 

पीवीएस-स्टूडियो चेतावनी: V578 एक अजीब बिटवाइज़ ऑपरेशन का पता चला। इसे सत्यापित करने पर विचार करें। bta_dm_co.cc 259

यह अभिव्यक्ति निरर्थक है। यदि आप सबप्रेप्रेशन (bte_appl_cfg.ble_auth_req & 0x04) निकालते हैं , तो अभिव्यक्ति का परिणाम नहीं बदलेगा। शायद यहाँ कुछ टाइपो है।

हैंडल लीक

 bool RSReflectionCpp::genEncodedBitCode() { FILE *pfin = fopen(mBitCodeFilePath.c_str(), "rb"); if (pfin == nullptr) { fprintf(stderr, "Error: could not read file %s\n", mBitCodeFilePath.c_str()); return false; } unsigned char buf[16]; int read_length; mOut.indent() << "static const unsigned char __txt[] ="; mOut.startBlock(); while ((read_length = fread(buf, 1, sizeof(buf), pfin)) > 0) { mOut.indent(); for (int i = 0; i < read_length; i++) { char buf2[16]; snprintf(buf2, sizeof(buf2), "0x%02x,", buf[i]); mOut << buf2; } mOut << "\n"; } mOut.endBlock(true); mOut << "\n"; return true; } 

PVS-Studio चेतावनी: V773 CWE-401 समारोह 'pfin' हैंडल जारी किए बिना बाहर किया गया था। एक संसाधन रिसाव संभव है।slang_rs_reflection_cpp.cpp 448

विश्लेषक ने सामान्य त्रुटि गणना के अनुसार इस त्रुटि को वर्गीकृत किया: CWE-401 : लास्ट रेफरेंस हटाने से पहले मेमोरी की अनुचित रिलीज़ ('मेमोरी लीक')। हालाँकि, CWE-775 : मिसिंग रिलीज़ ऑफ़ फ़ाइल डेसिप्टर या हैंडल को प्रभावी लाइफटाइम के बाद जारी करना यहाँ अधिक सही होगा । मैं अपने सहयोगियों को पीवीएस-स्टूडियो में इस दोष को ठीक करने का निर्देश दूंगा।

डिस्क्रिप्टर pfin कभी नहीं जारी किया। बस अंत में fclose फ़ंक्शन को कॉल करना भूल गया । एक अप्रिय गलती जो उपलब्ध डिस्क्रिप्टर की पूरी आपूर्ति को जल्दी से समाप्त कर सकती है, जिसके बाद नई फाइलें खोलना असंभव होगा।

निष्कर्ष

जैसा कि आप देख सकते हैं, यहां तक ​​कि एंड्रॉइड के रूप में इस तरह के एक प्रसिद्ध और अच्छी तरह से परीक्षण किए गए प्रोजेक्ट में, पीवीएस-स्टूडियो विश्लेषक आसानी से कई त्रुटियों और संभावित कमजोरियों का पता लगाता है। यह बताने के लिए कि क्या कमजोरियाँ (संभावित कमजोरियाँ) पाई गईं:

• CWE-14: क्लीयर बफ़र्स के लिए कोड हटाने वाला कंपाइलर
• CWE-20: अनुचित इनपुट सत्यापन
• CWE-119: मेमोरी बफ़र की सीमा के भीतर संचालन का अनुचित प्रतिबंध
• CWE-190: इंटेगर ओवरफ्लो या रैपराउंड
• CWE-198: गलत बाइट ऑर्डर का उपयोग
• CWE-393: गलत स्थिति कोड की वापसी
• CWE-401: अंतिम संदर्भ को हटाने से पहले मेमोरी की अनुचित रिलीज ('मेमोरी लीक')
• CWE-457: Uninitialized Variable का उपयोग
• CWE-462: एसोसिएटिव लिस्ट में डुप्लिकेट की
• CWE-480: गलत ऑपरेटर का उपयोग
• CWE-484: स्वीच में ब्रेकडाउन स्टेटमेंट
• CWE-561: डेड कोड
• CWE-562: रिटर्न ऑफ स्टैक वेरिएबल एड्रेस
• CWE-563: Assignment to Variable without Use
• CWE-570: Expression is Always False
• CWE-571: Expression is Always True
• CWE-476: NULL Pointer Dereference
• CWE-628: Function Call with Incorrectly Specified Arguments
• CWE-665: Improper Initialization
• CWE-670: Always-Incorrect Control Flow Implementation
• CWE-682: Incorrect Calculation
• CWE-688: Function Call With Incorrect Variable or Reference as Argument
• CWE-690: Unchecked Return Value to NULL Pointer Dereference
• CWE-691: Insufficient Control Flow Management
• CWE-758: Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
• CWE-762: Mismatched Memory Management Routines
• CWE-775: Missing Release of File Descriptor or Handle after Effective Lifetime
• CWE-783: Operator Precedence Logic Error
• CWE-824: Access of Uninitialized Pointer
• CWE-834: Excessive Iteration

कुल में, मैंने लेख में 490 संभावित कमजोरियों का वर्णन किया। वास्तव में, विश्लेषक उनमें से अधिक की पहचान करने में सक्षम है, लेकिन, जैसा कि मैंने पहले लिखा था, मुझे रिपोर्ट का अधिक ध्यान से अध्ययन करने की ताकत नहीं मिली।

परीक्षण किए गए कोड आधार का आकार C और C ++ में कोड की लगभग 2,168,000 लाइनें हैं। इनमें से 14.4% टिप्पणियां हैं। कुल मिलाकर, हमें लगभग 1,855,000 स्वच्छ कोड मिलते हैं।

इस प्रकार, हमारे पास कोड के 1,855,000 लाइनों के लिए 490 CWE हैं।

यह पता चला है कि पीवीएस-स्टूडियो विश्लेषक एक एंड्रॉइड प्रोजेक्ट में कोड की प्रत्येक 4000 लाइनों के लिए 1 से अधिक कमजोरी (संभावित भेद्यता) का पता लगाने में सक्षम है। एक कोड विश्लेषक के लिए अच्छा परिणाम, मुझे खुशी है।

आपका ध्यान के लिए धन्यवाद! मैं सभी को एक कोडलेस कोड की इच्छा देता हूं और निम्नलिखित करने का प्रस्ताव करता हूं:

1. पीवीएस-स्टूडियो डाउनलोड करें और काम के मसौदे की जांच करें।
2. : : .
3. , : twitter , RSS , vk.com .

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: एंड्रे कारपोव। We Checked the Android Source Codes by PVS-Studio or Nothing is Perfect