LINUX.ORG.RU

патч ядра не повился на lkml.org

 linux kernel patch


0

2

закоммитил ночью тривиальный патч, вот вывод процесса:

sbauer@metamini ~/devel/linux.release.git lan743x_virtual_phy$ git send-email --cc-cmd='./scripts/get_maintainer.pl --norolestats 0001-fix-for-potential-NULL-pointer-dereference.patch' -cc sbauer@blackbox.su 0001-fix-for-potential-NULL-pointer-dereference.patch
0001-fix-for-potential-NULL-pointer-dereference.patch
To whom should the emails be sent (if anyone)? 
Message-ID to be used as In-Reply-To for the first email (if any)? 
(cc-cmd) Adding cc: Bryan Whitehead <bryan.whitehead@microchip.com> from: './scripts/get_maintainer.pl --norolestats 0001-fix-for-potential-NULL-pointer-dereference.patch'
(cc-cmd) Adding cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com> from: './scripts/get_maintainer.pl --norolestats 0001-fix-for-potential-NULL-pointer-dereference.patch'
(cc-cmd) Adding cc: "David S. Miller" <davem@davemloft.net> from: './scripts/get_maintainer.pl --norolestats 0001-fix-for-potential-NULL-pointer-dereference.patch'
(cc-cmd) Adding cc: Jakub Kicinski <kuba@kernel.org> from: './scripts/get_maintainer.pl --norolestats 0001-fix-for-potential-NULL-pointer-dereference.patch'
(cc-cmd) Adding cc: netdev@vger.kernel.org from: './scripts/get_maintainer.pl --norolestats 0001-fix-for-potential-NULL-pointer-dereference.patch'
(cc-cmd) Adding cc: linux-kernel@vger.kernel.org from: './scripts/get_maintainer.pl --norolestats 0001-fix-for-potential-NULL-pointer-dereference.patch'
OK. Log says:
Server: blackbox.su
MAIL FROM:<sbauer@blackbox.su>
RCPT TO:<sbauer@blackbox.su>
RCPT TO:<bryan.whitehead@microchip.com>
RCPT TO:<UNGLinuxDriver@microchip.com>
RCPT TO:<davem@davemloft.net>
RCPT TO:<kuba@kernel.org>
RCPT TO:<netdev@vger.kernel.org>
RCPT TO:<linux-kernel@vger.kernel.org>
From: Sergej Bauer <sbauer@blackbox.su>
To: 
Cc: sbauer@blackbox.su,
        Bryan Whitehead <bryan.whitehead@microchip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: [PATCH] fix for potential NULL pointer dereference with bare lan743x
Date: Thu, 29 Oct 2020 03:28:45 +0300
Message-Id: <20201029002845.28984-1-sbauer@blackbox.su>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Result: 250


но на lkml.org он не появился, а только сейчас вылез на https://www.spinics.net/
я где-то косячу или на lkml завели премодерацию?

p.s. на spinics.net написано
To: unlisted-recipients:; (no To-header on input)

так как я не был уверен кому именно адресовать патч и поле «To:» оставил пустым... может, из-за этого?

★★★★★

Последнее исправление: metawishmaster (всего исправлений: 2)

На ЛОРе уже обсуждали, как находить свежеисправленные уязвимости в ядре, которые практически нигде в production ещё не залатаны? Если закоммичен патч, который не обсуждали на lkml, значит, вероятно, исправляет уязвимость. И только через некоторое время (может, месяцы спустя) об этом объявят.

gag ★★★★★
()
Ответ на: комментарий от gag

ну черт знает... когда я пытался просунуть патч для «виртуального» PHY, меня отфутболили «в режиме он-лайн» %)

но и на lkml.org он пришел сразу после моего «реквеста»

metawishmaster ★★★★★
() автор топика
Последнее исправление: metawishmaster (всего исправлений: 1)
Ответ на: комментарий от metawishmaster

Но у вас и не патч для уязвимости. Патчи для уязвимостей не посылают в открытые списки рассылок, а обсуждаются в закрытых. Но даже после объявления, что в ядре «новая» дырка давненько уже залатана, соответствующие ветки обсуждения не переносят в открытый архив, насколько мне известно. И это не очень хороший знак.

gag ★★★★★
()
Ответ на: комментарий от gag

да это и дырой-то назвать нельзя... но если «голой» железке без PHY («вырожденый» случай) сделать ethtool ethX, то будет «бум»:

$ sudo ethtool eth7
dmesg:
[  143.279234] BUG: kernel NULL pointer dereference, address: 0000000000000340
[  143.279318] #PF: supervisor read access in kernel mode
[  143.279369] #PF: error_code(0x0000) - not-present page
[  143.279419] PGD 0 P4D 0 
[  143.279453] Oops: 0000 [#1] SMP PTI
[  143.279493] CPU: 3 PID: 9459 Comm: ethtool Not tainted 5.9.0upstream+ #5
[  143.279556] Hardware name: Gigabyte Technology Co., Ltd. H110-D3/H110-D3-CF, BIOS F24 04/11/2018
[  143.279654] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy]
[  143.279710] Code: 00 48 85 c0 74 11 48 8b 80 40 01 00 00 48 85 c0 74 05 e9 8e ba 1a e7 b8 a1 ff ff ff c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <48> 8b 87 40 03 00 00 48 85 c0 74 11 48 8b 80 48 01 00 00 48 85 c0
[  143.279871] RSP: 0018:ffffa6f94053fcf0 EFLAGS: 00010286
[  143.279925] RAX: ffffffffc02f2d00 RBX: ffffa6f94053fd90 RCX: ffffffffa7efdd20
[  143.279990] RDX: 0000000000000001 RSI: ffffa6f94053fd90 RDI: 0000000000000000
[  143.280057] RBP: ffff91ef011e8000 R08: 0000000000001000 R09: 0000000000000000
[  143.280122] R10: 0000000000000000 R11: 0000000000000089 R12: 00007ffdd6fd1730
[  143.280188] R13: 0000000000000005 R14: ffff91ef011e8000 R15: 0000000000000000
[  143.280255] FS:  00007efe337b6740(0000) GS:ffff91f036d80000(0000) knlGS:0000000000000000
[  143.280329] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  143.280383] CR2: 0000000000000340 CR3: 0000000121ecc004 CR4: 00000000003706e0
[  143.280449] Call Trace:
[  143.280485]  lan743x_ethtool_get_wol+0x21/0x40 [lan743x]
[  143.280544]  dev_ethtool+0x1507/0x29d0
[  143.280589]  ? avc_has_extended_perms+0x17f/0x440
[  143.280640]  ? tomoyo_init_request_info+0x84/0x90
[  143.280688]  ? tomoyo_path_number_perm+0x68/0x1e0
[  143.280737]  ? tty_insert_flip_string_fixed_flag+0x82/0xe0
[  143.280792]  ? inet_ioctl+0x187/0x1d0
[  143.280835]  dev_ioctl+0xb5/0x560
[  143.280874]  sock_do_ioctl+0xa0/0x140
[  143.280916]  sock_ioctl+0x2cb/0x3c0
[  143.280957]  __x64_sys_ioctl+0x84/0xc0
[  143.281001]  do_syscall_64+0x33/0x80
[  143.281041]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  143.281091] RIP: 0033:0x7efe338a9427
[  143.281131] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48
[  143.281291] RSP: 002b:00007ffdd6fd1718 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  143.281363] RAX: ffffffffffffffda RBX: 00007ffdd6fd1730 RCX: 00007efe338a9427
[  143.281429] RDX: 00007ffdd6fd17b0 RSI: 0000000000008946 RDI: 0000000000000003
[  143.281494] RBP: 00007ffdd6fd17a0 R08: 000000000000021f R09: 00005627591a7670
[  143.281559] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[  143.281624] R13: 00007ffdd6fd17b0 R14: 00007ffdd6fd1910 R15: 0000000000000009
[  143.281691] Modules linked in: bnep bluetooth jitterentropy_rng drbg ecdh_generic ecc rfkill uinput loop lp snd_hda_codec_hdmi snd_hda_codec_generic ledtrig_audio i915 intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm i2c_algo_bit irqbypass drm_kms_helper drm crct10dif_pclmul ax88179_178a crc32_pclmul ghash_clmulni_intel usbnet snd_hda_intel snd_intel_dspcfg mii snd_hda_codec snd_hwdep aesni_intel glue_helper crypto_simd cryptd ppdev snd_hda_core rapl intel_cstate evdev iTCO_wdt intel_uncore snd_pcm mei_me iTCO_vendor_support pcspkr snd_timer snd mei soundcore button video parport_pc parport wmi ext4 crc32c_generic mbcache jbd2 usbmouse hid_generic usbkbd usbhid sg hid sd_mod t10_pi crc32c_intel xhci_pci lan743x ahci crc16 libahci xhci_hcd r8169 realtek i2c_i801 mdio_devres i2c_smbus libata e1000e usbcore scsi_mod libphy thermal
[  143.281977] CR2: 0000000000000340
[  143.281977] ---[ end trace ee76fac2a7d7635b ]---
[  143.281977] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy]
[  143.281977] Code: 00 48 85 c0 74 11 48 8b 80 40 01 00 00 48 85 c0 74 05 e9 8e ba 1a e7 b8 a1 ff ff ff c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <48> 8b 87 40 03 00 00 48 85 c0 74 11 48 8b 80 48 01 00 00 48 85 c0
[  143.281977] RSP: 0018:ffffa6f94053fcf0 EFLAGS: 00010286
[  143.281977] RAX: ffffffffc02f2d00 RBX: ffffa6f94053fd90 RCX: ffffffffa7efdd20
[  143.281977] RDX: 0000000000000001 RSI: ffffa6f94053fd90 RDI: 0000000000000000
[  143.281977] RBP: ffff91ef011e8000 R08: 0000000000001000 R09: 0000000000000000
[  143.281977] R10: 0000000000000000 R11: 0000000000000089 R12: 00007ffdd6fd1730
[  143.281977] R13: 0000000000000005 R14: ffff91ef011e8000 R15: 0000000000000000
[  143.285970] FS:  00007efe337b6740(0000) GS:ffff91f036d80000(0000) knlGS:0000000000000000
[  143.289971] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  143.289971] CR2: 0000000000000340 CR3: 0000000121ecc004 CR4: 00000000003706e0


и тривиальный патч

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от metawishmaster

да это и дырой-то назвать нельзя… но …

Я имел ввиду упомянутый вами другой патч, на который ответили: «add virtual PHY for PHY-less devices».

gag ★★★★★
()
Ответ на: комментарий от metawishmaster

если «голой» железке без PHY («вырожденый» случай) сделать ethtool ethX, то будет «бум»: …

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

If you have a patch that fixes an exploitable security bug, send that patch to security at kernel.org. For severe bugs, a short embargo may be considered to allow distributors to get the patch out to users; in such cases, obviously, the patch should not be sent to any public lists.

gag ★★★★★
()
Ответ на: комментарий от gag

хм... странно, не думал, что к этому багу можно отнестись как к security bug :-\
но спасибо за наводку, сейчас попробую...

metawishmaster ★★★★★
() автор топика
Последнее исправление: metawishmaster (всего исправлений: 1)
Ответ на: комментарий от metawishmaster

Я тоже не знаю, насколько он exploitable security или нет. Если ««голой» железке без PHY» в production не используются, то, значит, хоть и похож на security, но не exploitable, а, следовательно, неопасный: люди не побегут тут же ломать через сеть подключённые устройства.

Просто вспомнилось, что недавно где-то пробегало исследование о корреляции отсутствия обсуждения патчей на публичном lkml и их отношению к исправлению уязвимостей.

gag ★★★★★
()
Последнее исправление: gag (всего исправлений: 2)
Ответ на: комментарий от gag

в принципе, понятно почему исследование ошибок приводящим к эксплуатируемым уязвимостям должно быть доступно широким массам только после выхода поправленной версии

а в списке https://www.spinics.net/lists/netdev/ патч-таки появился

metawishmaster ★★★★★
() автор топика
Последнее исправление: metawishmaster (всего исправлений: 1)

В кои то веки на лоре нормальный технический тред по linux. Последний был года полтора назад? :)

anonymous
()
Ответ на: комментарий от anonymous

Для добавления в отслеживаемое надо залогиниться!

Дискриминация анонимуса! Есть куки есть webstorage есть текущая сессия в браузере наконецта! Дайте анонимусу нормально отслеживать ветви, пока я по лору гуляю в в 10 темах отписал не комельфо 10 вкладок держать что-бы отвечать.

anonymous
()
Ответ на: комментарий от metawishmaster

и тривиальный патч

а есть ли смысл для таких патчей ? вам же предложили еше когда отфутболили в первый раз использовать «затычку» - PHY c фиксированными параметрами, например как тут

https://elixir.bootlin.com/linux/v5.9.2/source/drivers/net/usb/lan78xx.c#L2044

на мой взгляд это практичней

spbob
()
Ответ на: комментарий от spbob

с fixed_phy я сделал, но еще не выкладывал, так-как пока нет времени разбить один патч на несколько, но на выходных займусь

а есть ли смысл для таких патчей ?

там просто забыли вставить проверку на NULL, во все остальных функциях она есть

metawishmaster ★★★★★
() автор топика
Ответ на: комментарий от metawishmaster

с fixed_phy я сделал, но еще не выкладывал
там просто забыли вставить проверку на NULL, во все остальных функциях она есть

если сделать с fixed_phy по такой же схеме как я привел в примере, эти проверки нужно будет всё равно убирать потому что NULL указатель на PHY уже никогда не будет - это будет пустой код.

PS хотя нет - если и fixed_phy не сможет зарегистрировать то будет NULL, так что всё правильно делаешь :)

spbob
()
Последнее исправление: spbob (всего исправлений: 1)
Ответ на: комментарий от spbob

в оригинальном драйвере

  static int lan743x_phy_init(struct lan743x_adapter *adapter)                         
  {                                                                                    
          return lan743x_phy_reset(adapter);                                           
  }    

проверку я сделал в lan743x_phy_open
   if (phynode) {
       ...                                                           
   } else {                                                                 
           phydev = phy_find_first(adapter->mdiobus);                       
           if (!phydev) {                                                   
                   phydev = lan743x_fake_phy(adapter, mii_regs,             
                                             mii_regs_count);               
                   if (!phydev || IS_ERR(phydev)) {                         
                           netif_err(adapter, ifup, adapter->netdev,        
                                     "cannot open PHY\n");                  
                           goto return_error;                               
                   }                                                        
           }                                                                
                                                                                   
           if (phy_is_pseudo_fixed_link(phydev)) {                          
                   ret = lan743x_fake_connect(netdev, phydev,               
                                              lan743x_phy_link_status_change,
                                              PHY_INTERFACE_MODE_GMII);     
                   netdev->wanted_features = netdev->features |             
                                  NETIF_F_LOOPBACK;                                
                                                                                   
                   netdev_update_features(netdev);                          
           } else {                                                         
                   ret = phy_connect_direct(netdev, phydev,                 
                                            lan743x_phy_link_status_change, 
                                            adapter->phy_mode);             
           }                                                                
                                                                                   
           if (ret)                                                         
                    goto return_error;                                       
    }      

схема похожа на приведеную Вами :)

metawishmaster ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.