10 anmärkningsvärda C- och C++-buggar som hittades i öppen källkodsprojekt år 2025

Under hela året har vi ridit över de stora slätten av öppen källkod, utreda brott, ta ut sårbarheter och samla troféer.Idag bestämde vi oss för att gå in i den dammigaste salongen: en erfaren sheriff lutar mot baren och påminner om tio av de djärvaste och farligaste buggarna i vilda västern. Vill du ha en intressant historia? Under hela året har vi kämpat med olika buggar från C- och C++-projekt med öppen källkod. Vi fångade var och en, förhörde den och registrerade dess missgärningar i filen. Idag ska jag berätta en historia om de 10 mest intressanta buggarna vi stött på i olika hörn av vilda västern. För var och en av dessa fragment har vi en separat fil – en fullständig artikel. Och för de mest dedikerade har vi valt ut 5 mest populära artiklar om C och C++-projekt som publicerats i år: Hur frivolös användning av polymorf allokatorer kan inkräkta på ditt liv C++ programmerarens guide till ospecificerat beteende Historien om C och C++. Del två: standardisering av C och C++, Qt, Clang och Unreal Engine std::array i C++ är snabbare än array i C. Safe array handling? aldrig hört talas om det Du kan hitta den fullständiga listan över artiklar från vår blogg på vår hemsida via länken. Länk Sitt ner, resenär, historien kommer att vara en lång N10 En gång hade vi ett fall om en saknad häst.Maren var alltid i stallet, men varje gång vi ville rida till staden, verkade den försvinna i tunn luft. The PVS-Studio warning: Den bokstavliga "0.5f" av typen "float" kastas implicit till typen "unsigned char" medan funktionen "SetRenderColor" kallas. 168 V674 För granatäpple.cpp typedef unsigned char byte; inline void CBaseEntity::SetRenderColor( byte r, byte g, byte b, byte a ) { m_clrRender.Init( r, g, b, a ); } void CGrenadeBugBait::BugBaitTouch( CBaseEntity *pOther ) { .... if ( pSporeExplosion ) { .... pSporeExplosion->SetRenderColor( 0.0f, 0.5f, 0.25f, 0.15f ); // <= .... } .... } The Funktionen sätter den färgvärden, där varje parameter är av den typ med ett möjligt värdeintervall av När man försöker förmedla argument från typ, den fraktionella delen kommer att trunkeras. och och och funktionsparametrar kommer att ha värden som är lika med . SetRenderColor RGBA unsigned char [0 .. 255] float r g b a 0 Tyvärr saknar lagret information om att skylla, så jag har två scenarier om hur detta fel dök upp i koden. Funktionen bearbetade en gång färger i en floating-point representation. bearbetningen ändrades senare till heltal, men inte alla samtal webbplatser uppdaterades. Utvecklaren trodde felaktigt att SetRenderColor hanterade flytande punktnummer och ställde in dem i enlighet därmed. Här är liknande varningar: V674 Den bokstavliga "0.5f" av typen "float" kastas implicit till typen "unsigned char" medan funktionen "SetRenderColor" kallas. V674 Den bokstavliga '25.6' av 'dubbel' typ kastas implicit till 'int' typ medan funktionen 'SetScrollRate' kallas. Kontrollera det första argumentet. grenade_tripmine.cpp 179 Vi upptäckte denna bugg i Source SDK-projektet. Du kan hitta hela artikeln på länken. Länk N9 Vi var en gång tvungna att rida hundra samma spår över prärien.Det hände så att vi vände oss till en vi redan hade ridit. PVS-Studio varnar för att: Användningen av "om (A) {...} annars om (A) {...}" mönster upptäcktes. Det finns en sannolikhet för förekomst av logiska fel. Kontrolllinjer: 2903, 3053. V517 ärl_bif_info.c 2903 BIF_RETTYPE system_info_1(BIF_ALIST_1) { .... if (is_tuple(BIF_ARG_1)) { // L2778 .... } else if (BIF_ARG_1 == am_scheduler_id) { // L2782 .... } .... else if (BIF_ARG_1 == am_garbage_collection) { // L2903 .... } else if (BIF_ARG_1 == am_fullsweep_after) { // L2921 .... } else if (BIF_ARG_1 == am_garbage_collection) { // L3053 .... } else if (BIF_ARG_1 == am_instruction_counts) { // L3056 .... } .... else if (ERTS_IS_ATOM_STR("halt_flush_timeout", BIF_ARG_1)) { // L3552 .... } } Analysatorn har upptäckt flera grenar med identiska kontroller i en funktion som innehåller ett stort antal uttalanden - Var och en av dem har dock en annan logik: och Med tanke på antalet grenar och gapet på 150 rader mellan dubbletterna är det knappast förvånande att detta kan hända. if-else if Ungefär 800 linjer Den första kontrollen Andra kontrollen Vi upptäckte denna bugg i Erlang-projektet; du kan hitta hela artikeln på länken. Länk N8 Jag kände en sheriff som bara hade en dom för alla brott: "Inte skyldig." PVS-Studio varnar för att: Uttrycket "då" motsvarar det följande kodfragmentet. V523 cmComputeLinkInformation.cxx 1748 bool cmComputeLinkInformation::CheckImplicitDirItem(LinkEntry const& entry) { BT const& item = entry.Item; // We only switch to a pathless item if the link type may be // enforced. Fortunately only platforms that support link types // seem to have magic per-architecture implicit link directories. if (!this->LinkTypeEnabled) { return false; } // Check if this item is in an implicit link directory. std::string dir = cmSystemTools::GetFilenamePath(item.Value); if (!cm::contains(this->ImplicitLinkDirs, dir)) { // Only libraries in implicit link directories are converted to // pathless items. return false; } // Only apply the policy below if the library file is one that can // be found by the linker. std::string file = cmSystemTools::GetFilenameName(item.Value); if (!this->ExtractAnyLibraryName.find(file)) { return false; } return false; } Analysören antyder att det definitivt är något fel med function: CheckImplicitDirItem den senare grenen av den sista om uttalandet duplicerar koden nedan (return false;); Varje gren av funktionens utförande slutar med falsk retur. when called from , it'll never trigger an early return; AddFullItem Den fullständiga funktionskroppen kan ersättas med retur falsk, eftersom detta inte kommer att ändra programbeteendet. Observera att funktionen är skriven med hjälp av " mönster som hjälper till att minska kodnätning: det mest positiva resultatet placeras i slutet av funktionen, och resten av koden - i händelse av avvikelse från funktionssyftet - bör avsluta funktionen så snart som möjligt. Tidig återkomst In our example, we can assume that the most "positive" result of the function is that an object of the typ har passerat alla nödvändiga kontroller med en Tillbaka värde . LinkEntry true Här är ett alternativ för hur man fixar koden: .... std::string file = cmSystemTools::GetFilenameName(item.Value); if (!this->ExtractAnyLibraryName.find(file)) { return false; } return true; Vi upptäckte denna bugg i CMake-projektet; du kan hitta hela artikeln på länken. Länk N7 En gång i en by såg jag en desperat spelare som satsade allt sitt guld på kortet som inte ens fanns i däcket. PVS-Studio varnar för att: Dereferencing av den ogiltiga iteratorn 'shades.end()' kan äga rum. V783 ColorHelper.cpp 194 winrt::Windows::UI::Color ColorHelper::GetAccentColor( const winrt::Windows::UI::Color& color ) { .... auto shades = std::map (); .... // 3f is quite nice if the whole non-client area is painted constexpr auto readability = 1.75f; for (auto shade : shades) { if (shade.first >= readability) { return HslToRgb(shade.second); } } return HslToRgb(shades.end()->second); // <= } Är det möjligt att ingen av nyanserna kommer att uppfylla läsbarhetskriterierna? Vi kan inte säga säkert, men det är ganska troligt. av — behöver inte blinka något psykiskt papper för att bevisa det, eftersom dereferencing orsakar exakt det, eftersom denna iterator pekar precis förbi det sista elementet i en . Textbook fall Odefinierat beteende std::map::end() std::map Vi upptäckte denna bugg i Windows Terminal-projektet; du kan hitta hela artikeln på länken. Länk N6 Jag gjorde en gång en affär med en medresenär för att dela upp en skatt vi hittade.Han knäppte, vände sig om och försvann som en mirakel. PVS-Studio varnar för att: Referensen "graf" blir ogiltig när den smarta pekaren som returneras av en funktion förstörs. V758 För Föregående Föregående inlägg: Cpp 391 template struct Ptr : public std::shared_ptr ; // .... Ptr FlannNeighborhoodGraph::create( const Mat &points, int points_size, int k_nearest_neighbors_, bool get_distances, int flann_search_params_, int num_kd_trees) { return makePtr (points, points_size, k_nearest_neighbors_, get_distances, flann_search_params_, num_kd_trees); } void Utils::densitySort (const Mat &points, int knn, Mat &sorted_points, std::vector &sorted_mask) { // .... // get neighbors FlannNeighborhoodGraph &graph = // sum_knn_distances (points_size, 0); for (int p = 0; p &dists = graph.getNeighborsDistances(p); for (int k = 0; k struct Ptr : public std::shared_ptr { inline Ptr(const std::shared_ptr & o) CV_NOEXCEPT : std::shared_ptr (o) {} inline Ptr(std::shared_ptr && o) CV_NOEXCEPT : std::shared_ptr (std::move(o)) {} typename std::add_lvalue_reference ::type operator*() const CV_NOEXCEPT { return *std::shared_ptr ::get(); } // .... } template static inline Ptr makePtr(const A1&... a1) { static_assert( !has_custom_delete ::value, "Can't use this makePtr with custom DefaultDeleter"); return (Ptr )std::make_shared (a1...); } Att använda smarta pekare löser inte problemen med att krypa referenser och minnesåtkomst här.Låt oss gräva in i detta. Skapa-funktionen skapar och returnerar en smart pekare till FlannNeighborhoodGraphImpl-typen, och dess objektreferensantal är ett. Grafreferensen skapas för värdet för den här smarta pekaren medan objektreferensantalet förblir oförändrat. Eftersom pekaren är ett tillfälligt objekt når referensräknaren null efter initialisering, vilket frigör det hanterade objektet. Den för loop referenser en ogiltig referens. Som ett resultat leder den kod som verkade korrekt till odefinierat beteende. Dessutom är PVS-Studio inte det enda verktyget som upptäcker detta problem; sanitizer gör det också. . Bevis För att åtgärda detta måste vi spara den smarta pekaren så att objektet kvarstår till slutet av blocket. Till exempel kan vi göra : FlannNeighborhoodGraph Så här här std::vector sum_knn_distances (points_size, 0); { // get neighbors auto graph = FlannNeighborhoodGraph::create(points, points_size, knn, true /*get distances */, 6, 1); for (int p = 0; p &dists = graph->getNeighborsDistances(p); for (int k = 0; k < knn; k++) sum_knn_distances[p] += dists[k]; } } Vi begränsar också räckvidd för att frigöra resursen efter looputförandet. graph We detected this bug in the OpenCV project; you can find the full article at the . Länk N5 En gång, en lokal expert ritade en karta över en flod korsning, men han sprang ut av kol. Så, den farligaste delen, ritad med de sista bitarna av kol, tvättas bort med den första regnet. PVS-Studio varnar för följande: Överväga att inspektera uttrycket "1 typ + 1)". bitskifte av 32-bitarsvärdet med en efterföljande expansion till 64-bitars typ. V629 phpdbg_bp.c 1209 Övrigt Storleken på bitmasken är mindre än storleken på den första operanden. V780 phpdbg_bp.c 1209 uint64_t flags .... PHPDBG_API void phpdbg_delete_breakpoint(zend_ulong num) { .... if ((brake = phpdbg_find_breakbase_ex(num, &table, &numkey, &strkey))) { int type = brake->type; char *name = NULL; size_t name_len = 0L; switch (type) { .... default: { if (zend_hash_num_elements(table) == 1) { PHPDBG_G(flags) &= ~(1 type+1)); // type int flags Den 1 konstanten av int-typen flyttas kvar av ett visst antal bitar.Oftast är int-typen 32 bitar.Vi hoppas att skiftet inte är av 32 eller fler bitar, annars får vi odefinierat beteende. Resultatet av skiftet är bitvis inverterat. Resultatet av inverteringen har fortfarande int-typen. The result of the inversion is expanded to a 64-bit unsigned type due to the left operand. Since the original type is signed, sign extension will occur. This means that for positive numbers, the 32 most significant bits will contain zero bits, and for negative numbers, they'll contain ones. Bitvis "AND" tillämpar konverteringsresultatet på flaggor. Förlusten av signifikanta bitar i flaggor kommer att inträffa när den högra operanden är positiv. Det kommer bara att vara så när det finns en 31-bitarsskift till vänster – när den 31:e biten i flaggor måste tas bort. Fånga ett bevis. Observera hur mycket vi behöver komma ihåg för ett sådant ofarligt uttryck? Problemet ligger i de olika operandstorlekarna och tecknen på vissa underuttryck. För att fixa det behöver utvecklarna bara ändra typen av Konstant från Två , och koden kommer att utföra som avsett: 1 int unsigned long long PHPDBG_G(flags) &= ~( 1uLL type+1)); We discovered this bug in the PHP project; you can find the full article via the . link N4 I once saw a young cowboy chasing an outlaw. He cornered him in a dead end in one of the local bars, but he fired not at the criminal, but at his own reflection in a dusty mirror, shattering it to pieces. The PVS-Studio warning: The assignment operator should be protected from the case of 'this == &other'. V794 fs_path.cpp 13 FsPath& FsPath::operator=(FsPath&& other) { m_path = std::move(other.m_path); other.m_path.clear(); return *this; } I det här avsnittet har vi flytt tilldelningsoperatören för class, which transfers data from the other object to the current instance. However, there's no check for self-assignment som kan leda till oavsiktliga konsekvenser. FsPath (this == &other) Om ett försök görs att tilldela objektet till sig själv, Operationen flyttar innehållet i in i och den efterföljande uppmaningen till clears the data. As a result, ends up in an unexpected state, and one can only wish developers happy debugging :) m_path = std::move(other.m_path); other.m_path m_path other.m_path.clear(); m_path To eliminate the risk, we recommend adding the following check at the beginning of the operator: if (this == std::addressof(other)) { return *this; } Using instead of the operator ensures correct address comparison even when the operator är överbelastad i klassen. std::addressof & & Vi upptäckte denna bugg i Nau Engine-projektet; du kan hitta hela artikeln på länken. Länk N3 Jag såg en gång en schaman som försökte kalla en ande utan att nå de heliga platserna.En ande kom, men det var en helt annan – en coyote från närmaste ravinen. PVS-Studio varnar för att: sing the 'window_id' function of uninitialized derived class while initializing the 'modal_dialog' base class will lead to undefined behavior. 29 V1099 install_dependencies.hpp class install_dependencies : public modal_dialog { public: explicit install_dependencies(const addons_list& addons) : modal_dialog(window_id()), addons_(addons) // <= {} .... private: virtual const std::string& window_id() const override; .... } Thanks to this code snippet, I can tell you more about undefined behavior. As we can see above, the class is derived from the class. In the konstruktor, är basklassen initialiserad med värdet som returneras av (vänta på det ...) den icke-statiska funktionen. så här kommer det att hända: install_dependencies modal_dialog install_dependencies window_id Execution of the initialization list: a call to the method; install_dependencies::window_id a constructor call to the class; modal_dialog an initialization of the data member; addons_ Exekvering av konstruktorkroppen för install_dependencies-klassen. This results in a function call of a class object which hasn't been initialized yet! This violates the following : Regeln för standarden Member functions (including virtual member functions, [class.virtual]) can be called for an object under construction Similarly, an object under construction can be the operand of the typeid operator ([expr.typeid]) or of a dynamic_cast ([expr.dynamic.cast]). However, if these operations are performed in a ctor-initializer (or in a function called directly or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the program has undefined behavior. Men vänta, det finns mer! Som du kanske har märkt, den member function is virtual and overridden in the class. Issues may arise later when a programmer writes a derived class where är överdriven . window_id install_dependencies window_id When an object of this derived class is created and the constructor is executed, there's no information about the existence of the new override yet. So, the funktionen kommer alltid att kallas i initialiseringslistan. Detta kan skilja sig från utvecklarnas ursprungliga avsikt. . installed_dependencies installed_dependencies::window_id here Vi upptäckte denna bugg i Wesnoth-projektet; du kan hitta hela artikeln på länken. Länk N2 Jag kände en cowboy som sköt på en skugga på väggen, förvirrade den för en lurande fiende. Skottet boomade, gipset krossade, lämnade bara ett hål i väggen. The PVS-Studio warning: The null pointer is passed into 'fseek' function. Inspect the first argument. V575 vid_ati_eeprom.se 61 void ati_eeprom_load_mach8(ati_eeprom_t *eeprom, char *fn, int mca) { FILE *fp; .... fp = nvr_fopen(eeprom->fn, "rb"); size = 128; if (!fp) { if (mca) { (void) fseek(fp, 2L, SEEK_SET); // data + 2, 0xff, size - 2); fp = nvr_fopen(eeprom->fn, "wb"); fwrite(eeprom->data, 1, size, fp); .... } We need to load data stored in the video adapter's NVRAM, which we keep in a binary file. If the file doesn't exist, we need to create it with "default" data. Let's look at the case where the file is missing. We shift the file pointer, but it's null. As a result, we get an Null pointer avlägsnande. fp Låt oss ta en närmare titt på . The standard definierar inte krav för funktionens första parameter och garanterar inte en kontroll av . This means it's up to the standard library developers to handle it properly. Now let's welcome: fseek C11 NULL GNU glibc; BSD libc from FreeBSD 14.3; Microsoft Universal CRT från Windows SDK 10.0.26100; musl v1.2.5. De två sista C-standardbiblioteksimplementationerna är här som gäster: 86Box är inte utformad för att fungera med dem, eller deras kompatibilitet har inte kontrollerats. don't mention alternative implementations either. So, let's start with the expected standard libraries and ask them to repeat the same actions with a null file pointer. Bygg instruktioner Flicking the power switch Vi tar en IBM PS/2 modell 55SX från den imaginära hyllan och "plug in" IBM 8514/A 2D accelerator gjord av ATI. Det första testämnet är en Windows-instans byggd med MinGW. Vi ser till att NVRAM-filen är frånvarande innan vi startar – vi kontrollerar Direktör för den . file. If it is there, we delete it. %userprofile%\86Box VMs\ \nvr ati8514_mca.nvr Turning on the power supply, and... är Inget exploderade! Allt är bra: NVRAM-filen är skriven, datorn körs och röktestet på glibc är slutfört. är Moving on to FreeBSD. The libc library implements the standard C library in this OS. This is generally true for all BSD-family operating systems. We use the same configuration. We check for the absence of the NVRAM-fil vid den Tre, två, en, makten är på... ati8514_mca.nvr ~/.local/share/86Box/Virtual Machines/ /nvr är Well, only an event from recent past could better describe this situation :) ”Ben Grubbs” är Efter att ha öppnat våra ögon, klämda stängda efter explosionen, tittar vi på konsolen: vi har bekräftat en onormal utgång! void VMManagerSystem::launchMainProcess() Full Command: "/root/86Box/build_freebsd/src/86Box" ("--vmpath", "/root/.local/share/86Box/Virtual Machines/somevm", "--vmname", "somevm") Connection received on 86Box.socket.5876c5 Connection disconnected Abnormal program termination while launching main process: exit code 11, exit status QProcess::CrashExit En kärn dump fil dök upp bredvid emulator körbar. Låt oss välkomna LLDB: root@freebsd:~/86Box/build_freebsd/src # lldb 86Box -c 86Box.core (lldb) target create "86Box" --core "86Box.core" Core file '/root/86Box/build_freebsd/src/86Box.core' (x86_64) was loaded. (lldb) bt * thread #1, name = '86Box', stop reason = signal SIGSEGV * frame #0: 0x0000000832f880bf libc.so.7`_flockfile(fp=0x0000000000000000) at _flock_stub.c:65:20 frame #1: 0x0000000832f8b675 libc.so.7`fseek(fp=0x0000000000000000, offset=2, whence=0) at fseek.c:62:2 frame #2: 0x00000000018cd964 86Box`ati_eeprom_load_mach8(eeprom=...., fn= , mca=1) at vid_ati_eeprom.c:61:20 The null pointer gör en spektakulär brandshow - det fanns inget sätt att låsa filen eftersom dess beskrivare är ogiltig. or with a loud boom and special effects. Therefore, I can't show you how the code is executed like in Windows. fp lost connection Vi upptäckte denna bugg i 86Box-projektet; du kan hitta hela artikeln på länken. Länk N1 En sheriff som jag känner från en grannstad skrev en gång i en förhörstranscript att ett vittne hade bekräftat sitt eget vittnesmål. PVS-Studio varnar för att: Det finns identiska underuttryck till vänster och höger om "==" -operatorn: PeekArg.getValNo() == PeekArg.getValNo() V501 Föregående Föregående inlägg: PPCISelLowering.cpp 7865 SDValue PPCTargetLowering::LowerCall_AIX(....) const { .... for (unsigned I = 0, E = ArgLocs.size(); I != E;) { .... CCValAssign &GPR1 = VA; .... if (I != E) { // If only 1 GPR was available, there will only be one custom GPR and // the argument will also pass in memory. CCValAssign &PeekArg = ArgLocs[I]; if (PeekArg.isRegLoc() && PeekArg.getValNo() == PeekArg.getValNo()) // <= { assert(PeekArg.needsCustom() && "A second custom GPR is expected."); CCValAssign &GPR2 = ArgLocs[I++]; RegsToPass.push_back(std::make_pair(GPR2.getLocReg(), DAG.getZExtOrTrunc(ArgAsInt, dl, MVT::i32))); } } .... } Vi antar för tillfället att det är ännu ett offer för kopieringspasta. Har några biverkningar: getValNo class CCValAssign{ .... unsigned ValNo; unsigned getValNo() const { return ValNo; } } Inget konstigt här, men titta på den sista : Komma till CCValAssign &GPR1 = VA; .... assert(I != E && "A second custom GPR is expected!"); CCValAssign &GPR2 = ArgLocs[I++]; assert(GPR2.isRegLoc() && GPR2.getValNo() == GPR1.getValNo() && GPR2.needsCustom() && "A second custom GPR is expected!"); RegsToPass.push_back( std::make_pair(GPR2.getLocReg(), DAG.getZExtOrTrunc(ArgAsInt, dl, MVT::i32))); Tanken är tydlig: ett undantagsfall som tidigare skyddades av ett påstående omdesignades till en vanlig gren. Denna patch implementerar caller-sidan för att placera funktionssamtalargument in stack memory. This removes the current limitation where LLVM on AIX kommer att rapportera ett dödligt fel när argument inte kan finnas i register. Observera att förutom det hittade felet finns det en annan konstig tilldelning: CCValAssign &PeekArg = ArgLocs[I]; .... CCValAssign &GPR2 = ArgLocs[I++]; // here PeekArg == GPR2 Utvecklaren kanske har för avsikt att skriva något så här: if (I != E) { CCValAssign &GPR2 = ArgLocs[I]; if (GPR2.isRegLoc() && PeekArg.getValNo() == GPR1.getValNo()) { assert(PeekArg.needsCustom() && "A second custom GPR is expected."); I++; RegsToPass.push_back(std::make_pair( GPR2.getLocReg(), DAG.getZExtOrTrunc(ArgAsInt, dl, MVT::i32))); } } Men för tydlighetens skull bröt utvecklarna ut from to show that, unlike the previous unconditional code, the argument now needs to be "peeked" first. And during the copy-paste process, Av en slump föll han ur sitt tillstånd. PeekArg GPR2 GPR1 The corrected Förmodligen borde vara: if if (PeekArg.isRegLoc() && PeekArg.getValNo() == GPR1.getValNo()) Interestingly, before migrating to GitHub, LLVM had a code review platform, and the commit included a Där kan vi se att manuell granskning inte alltid kan rädda situationen: Länk är Vi hittade denna bugg i LLVM-projektet, hela artikeln finns på länken. link Conclusion Tystnaden föll över salongen, bruten bara av öppningen av ytterdörren och knäckandet av loggarna i eldstaden.Tio av de mest djärva buggarna av 2025 är nu bara historier som överförs från generation till generation. I det här vilda västern kan du inte komma långt utan en pålitlig partner, så min pålitliga hjälpare i varje fall har varit analyzer. It's ready to help you find dangerous code snippets: PVS-Studio för open source-projekt for educational purposes; using a for a glorious beginning. 30-day trial version Och om din väg leder dig till andra territorier, föreslår jag att du lyssnar på historier om buggar från projekt som är skrivna i Java och C#. Topp 10 anmärkningsvärda Java-fel år 2025 . Top 10 errors found in C# projects in 2025