Page 26 of 2866 results (0.005 seconds)

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: phy: fix null-ptr-deref while probe() failed I got a null-ptr-deref report as following when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x23e/0x2d0 bus_remove_device+0x1bd/0x240 device_del+0x357/0x770 phy_device_remove+0x11/0x30 mdiobus_unregister+0xa5/0x140 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 device_unbind_cleanup+0x19/0xd0 //probe path: phy_device_register() device_add() phy_connect phy_attach_direct() //set device driver probe() //it's failed, driver is not bound device_bind_driver() // probe failed, it's not called //remove path: phy_device_remove() device_del() device_release_driver_internal() __device_release_driver() //dev->drv is not NULL klist_remove() <- knode_driver is not added yet, cause null-ptr-deref In phy_attach_direct(), after setting the 'dev->driver', probe() fails, device_bind_driver() is not called, so the knode_driver->n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev->driver to NULL in the error path in phy_attach_direct(). • https://git.kernel.org/stable/c/e13934563db047043ccead26412f552375cea90c https://git.kernel.org/stable/c/8aaafe0f71314f46a066382a047ba8bb3840d273 https://git.kernel.org/stable/c/51d7f6b20fae8bae64ad1136f1e30d1fd5ba78f7 https://git.kernel.org/stable/c/0744c7be4de564db03e24527b2e096b7e0e20972 https://git.kernel.org/stable/c/3e21f85d87c836462bb52ef2078ea561260935c1 https://git.kernel.org/stable/c/fe6bc99c27c21348f548966118867ed26a9a372c https://git.kernel.org/stable/c/7730904f50c7187dd16c76949efb56b5fb55cd57 https://git.kernel.org/stable/c/eaa5722549ac2604ffa56c2e946acc832 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/9p: Fix a potential socket leak in p9_socket_open Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak. This patch adds sock_release() to fix the leak issue. • https://git.kernel.org/stable/c/6b18662e239a032f908b7f6e164bdf7e2e0a32c9 https://git.kernel.org/stable/c/0396227f4daf4792a6a8aaa3b7771dc25c4cd443 https://git.kernel.org/stable/c/ded893965b895b2dccd3d1436d8d3daffa23ea64 https://git.kernel.org/stable/c/8b14bd0b500aec1458b51cb621c8e5fab3304260 https://git.kernel.org/stable/c/2d24d91b9f44620824fc37b766f7cae00ca32748 https://git.kernel.org/stable/c/e01c1542379fb395e7da53706df598f38905dfbf https://git.kernel.org/stable/c/8782b32ef867de7981bbe9e86ecb90e92e8780bd https://git.kernel.org/stable/c/aa08323fe18cb7cf95317ffa2d54ca1de •

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/492caffa8a1a405f661c111acabfe6b8b9645db8 https://git.kernel.org/stable/c/910c0264b64ef2dad8887714a7c56c93e39a0ed3 https://git.kernel.org/stable/c/45752af0247589e6d3dede577415bfe117b4392c https://git.kernel.org/stable/c/9c584d6d9cfb935dce8fc81a4c26debac0a3049b https://git.kernel.org/stable/c/80e82f7b440b65cf131dce10f487dc73a7046e6b https://git.kernel.org/stable/c/9256db4e45e8b497b0e993cc3ed4ad08eb2389b6 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: hsr: Fix potential use-after-free The skb is delivered to netif_rx() which may free it, after calling this, dereferencing skb may trigger use-after-free. • https://git.kernel.org/stable/c/f421436a591d34fa5279b54a96ac07d70250cc8d https://git.kernel.org/stable/c/8393ce5040803666bfa26a3a7bf41e44fab0ace9 https://git.kernel.org/stable/c/4b351609af4fdbc23f79ab2b12748f4403ea9af4 https://git.kernel.org/stable/c/b35d899854d5d5d58eb7d7e7c0f61afc60d3a9e9 https://git.kernel.org/stable/c/53a62c5efe91665f7a41fad0f888a96f94dc59eb https://git.kernel.org/stable/c/7ca81a161e406834a1fdc405fc83a572bd14b8d9 https://git.kernel.org/stable/c/dca370e575d9b6c983f5015e8dc035e23e219ee6 https://git.kernel.org/stable/c/f3add2b8cf620966de3ebfa07679ca12d •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix use-after-free in tun_detach() syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done. • https://git.kernel.org/stable/c/83c1f36f9880814b24cdf6c2f91f66f61db65326 https://git.kernel.org/stable/c/1f23f1890d91812c35d32eab1b49621b6d32dc7b https://git.kernel.org/stable/c/16c244bc65d1175775325ec0489a5a5c830e02c7 https://git.kernel.org/stable/c/5f442e1d403e0496bacb74a58e2be7f500695e6f https://git.kernel.org/stable/c/04b995e963229501401810dab89dc73e7f12d054 https://git.kernel.org/stable/c/4cde8da2d814a3b7b176db81922d4ddaad7c0f0e https://git.kernel.org/stable/c/5daadc86f27ea4d691e2131c04310d0418c6cd12 •