د بخښنې د پرانیستې لیک په تعقیب، د مینیسوټا پوهنتون د څیړونکو یوې ډلې، چې د لینوکس کرنل کې د بدلونونو منل د ګریګ کروه هارتمن لخوا بند شوي، د کرنل پراختیا کونکو ته لیږل شوي پیچونو او د ساتونکو سره د اړیکو په اړه مفصل معلومات افشا کړل. د دې پیچونو سره تړاو لري.
د یادونې وړ ده چې ټولې ستونزې لرونکي پیچونه د ساتونکو په نوښت رد شوي؛ یوه پیچ هم تصویب نه شو. دا حقیقت دا روښانه کوي چې ولې ګریګ کروه هارتمن دومره سخت عمل وکړ، ځکه چې دا څرګنده نده چې څیړونکو به څه کړي وي که چیرې پیچ د ساتونکو لخوا تصویب شوی وای. په پټه توګه ، دوی ادعا وکړه چې دوی د بګ راپور ورکولو اراده لري او پیچونو ته به اجازه نه ورکوي چې ګیټ ته لاړ شي ، مګر دا څرګنده نده چې دوی به واقعیا څه کړي وي او څومره لرې تللي وي.
د 2020 په اګست کې ټول د نامعلومو پتو څخه [ایمیل خوندي شوی] и [ایمیل خوندي شوی] (د جیمز بانډ لیک) پنځه پیچونه لیږل شوي: دوه سم (1، 2) او درې یې پټې غلطۍ لري (1, 2, 3)، د زیانونو لپاره شرایط رامینځته کوي. په هر پیچ کې د کوډ یوازې 1-4 کرښې شاملې وې. د غلطو پیچونو ترشا اصلي نظر دا و چې د حافظې لیک فکس کول کولی شي دوه ځله وړیا زیانمنونکي حالت رامینځته کړي. یوه اونۍ وروسته ، معلومات د کرنل پراختیا کونکو ته د وړاندیز سره واستول شول ترڅو د حافظې لیکونو لپاره د کوچني فکسونو په پلمه د زیانونو هڅولو احتمال په اړه بحث وکړي ، مګر د ناوړه پیچونو لیږلو پخوانیو هڅو په اړه څه ندي ویل شوي.
لومړۍ ستونزه لرونکې پیچ د یوې تېروتنې په صورت کې د کنټرول بیرته راستنیدو دمخه kfree() ته د زنګ په اضافه کولو سره د حافظې لیک حل کړ ، مګر د حافظې ساحې ته د لاسرسي لپاره شرایط رامینځته کړل وروسته له دې چې خلاص شو (استعمال وروسته - وړیا). دا پیچ د ساتونکي (جیري سلیبي) لخوا رد شو چې ستونزه یې په ګوته کړه او په ګوته یې کړه چې یو کال دمخه یو چا هڅه کړې وه چې د ورته بدلون وړاندیز وکړي او په لومړي سر کې ومنل شو، مګر وروسته د ضعیف شرایطو له پیژندلو وروسته رد شو. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL؛ > - که (! p2) بیرته راستانه شي -ENOMEM؛ > + که (!p2) { > + kfree(p1); > + بیرته ستنیدل -ENOMEM؛ > + }
دویمه پیچ د کارولو وروسته د وړیا ستونزې لپاره شرایط هم لري. ټاکل شوی پیچ د ساتونکي (ډان کارپینټر) لخوا ونه منل شو ، چا چې د لیست_add_tail سره د بلې ستونزې له امله پیچ رد کړ ، مګر دا یې ونه ویل چې د "chdev" پوائنټر د put_device فنکشن کې خلاص کیدی شي ، کوم چې لاندې په زنګ کې کارول کیږي dev_err(&chdev ->dev..). په هرصورت، پیچ ونه منل شو، که څه هم د دلیلونو لپاره د زیان مننې سره تړاو نلري. که (ret <0) { + put_device(&chdev->dev)؛ dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc ناکام\n"); ret = -ENOMEM; لاړ شه err_fifo;
دریم پیچ هم د ساتونکي (میکیل رینل) لخوا نه و منل شوی ځکه چې د بلې بګ له امله چې د زیان سره تړاو نلري (د pdev لپاره دوه ځله زنګ وهل). که (!window->virt) { printk(KERN_ERR MOD_NAME": ioremap(%08lx, %08lx) ناکام\n", window->phys, window->size); + pci_dev_put(pdev); بهر لاړ } ... که (! نقشه) { printk(KERN_ERR MOD_NAME ": kmalloc ناکام شوی"); + pci_dev_put(pdev); بهر لاړ } memset(نقشه، 0، اندازه (*نقشه))؛ ... که (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); نقشه->mtd = NULL؛ + pci_dev_put(pdev); بهر لاړ }
په زړه پورې خبره دا ده چې په پیل کې له 4 پیچونو څخه 5 داسې انګیرل شوي چې ستونزې لري ، مګر څیړونکو پخپله غلطي وکړه او په یوه پیچ کې چې ستونزه وه ، د دوی په نظر ، د وړیا پیښې وروسته د حافظې کارولو لپاره تمه شوي شرایطو پرته ، د سم حل وړاندیز شوی و. err = pci_request_mem_regions(pdev, nitrox_driver_name); که (غلطي) { pci_disable_device(pdev)؛ + dev_err(&pdev->dev, "د یاد سیمو غوښتنه کولو کې پاتې راغلی!\n"); بیرته ستنیدل }
سرچینه: opennet.ru