Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: sn-f-ospi: Fix division by zero<br /> <br /> When there is no dummy cycle in the spi-nor commands, both dummy bus cycle<br /> bytes and width are zero. Because of the cpu&amp;#39;s warning when divided by<br /> zero, the warning should be avoided. Return just zero to avoid such<br /> calculations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hid-thrustmaster: fix stack-out-of-bounds read in usb_check_int_endpoints()<br /> <br /> Syzbot[1] has detected a stack-out-of-bounds read of the ep_addr array from<br /> hid-thrustmaster driver. This array is passed to usb_check_int_endpoints<br /> function from usb.c core driver, which executes a for loop that iterates<br /> over the elements of the passed array. Not finding a null element at the end of<br /> the array, it tries to read the next, non-existent element, crashing the kernel.<br /> <br /> To fix this, a 0 element was added at the end of the array to break the for<br /> loop.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=9c9179ac46169c56c1ad

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> workqueue: Put the pwq after detaching the rescuer from the pool<br /> <br /> The commit 68f83057b913("workqueue: Reap workers via kthread_stop() and<br /> remove detach_completion") adds code to reap the normal workers but<br /> mistakenly does not handle the rescuer and also removes the code waiting<br /> for the rescuer in put_unbound_pool(), which caused a use-after-free bug<br /> reported by Cheung Wall.<br /> <br /> To avoid the use-after-free bug, the pool’s reference must be held until<br /> the detachment is complete. Therefore, move the code that puts the pwq<br /> after detaching the rescuer from the pool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vrf: use RCU protection in l3mdev_l3_out()<br /> <br /> l3mdev_l3_out() can be called without RCU being held:<br /> <br /> raw_sendmsg()<br /> ip_push_pending_frames()<br /> ip_send_skb()<br /> ip_local_out()<br /> __ip_local_out()<br /> l3mdev_ip_out()<br /> <br /> Add rcu_read_lock() / rcu_read_unlock() pair to avoid<br /> a potential UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: fix a oob in orangefs_debug_write<br /> <br /> I got a syzbot report: slab-out-of-bounds Read in<br /> orangefs_debug_write... several people suggested fixes,<br /> I tested Al Viro&amp;#39;s suggestion and made this patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array<br /> <br /> The loop that detects/populates cache information already has a bounds<br /> check on the array size but does not account for cache levels with<br /> separate data/instructions cache. Fix this by incrementing the index<br /> for any populated leaf (instead of any populated level).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> team: better TEAM_OPTION_TYPE_STRING validation<br /> <br /> syzbot reported following splat [1]<br /> <br /> Make sure user-provided data contains one nul byte.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline]<br /> BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714<br /> string_nocheck lib/vsprintf.c:633 [inline]<br /> string+0x3ec/0x5f0 lib/vsprintf.c:714<br /> vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843<br /> __request_module+0x252/0x9f0 kernel/module/kmod.c:149<br /> team_mode_get drivers/net/team/team_core.c:480 [inline]<br /> team_change_mode drivers/net/team/team_core.c:607 [inline]<br /> team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401<br /> team_option_set drivers/net/team/team_core.c:375 [inline]<br /> team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543<br /> genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]<br /> netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348<br /> netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892<br /> sock_sendmsg_nosec net/socket.c:718 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:733<br /> ____sys_sendmsg+0x877/0xb60 net/socket.c:2573<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627<br /> __sys_sendmsg net/socket.c:2659 [inline]<br /> __do_sys_sendmsg net/socket.c:2664 [inline]<br /> __se_sys_sendmsg net/socket.c:2662 [inline]<br /> __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662<br /> x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: Fix crash on error in gpiochip_get_ngpios()<br /> <br /> The gpiochip_get_ngpios() uses chip_*() macros to print messages.<br /> However these macros rely on gpiodev to be initialised and set,<br /> which is not the case when called via bgpio_init(). In such a case<br /> the printing messages will crash on NULL pointer dereference.<br /> Replace chip_*() macros by the respective dev_*() ones to avoid<br /> such crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: bail out when failed to load fw in psp_init_cap_microcode()<br /> <br /> In function psp_init_cap_microcode(), it should bail out when failed to<br /> load firmware, otherwise it may cause invalid memory access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw: fix memleak in certain XDP cases<br /> <br /> If the XDP program doesn&amp;#39;t result in XDP_PASS then we leak the<br /> memory allocated by am65_cpsw_build_skb().<br /> <br /> It is pointless to allocate SKB memory before running the XDP<br /> program as we would be wasting CPU cycles for cases other than XDP_PASS.<br /> Move the SKB allocation after evaluating the XDP program result.<br /> <br /> This fixes the memleak. A performance boost is seen for XDP_DROP test.<br /> <br /> XDP_DROP test:<br /> Before: 460256 rx/s 0 err/s<br /> After: 784130 rx/s 0 err/s

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: csum: Fix OoB access in IP checksum code for negative lengths<br /> <br /> Commit 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit<br /> system") would cause an undefined shift and an out-of-bounds read.<br /> <br /> Commit 8bd795fedb84 ("arm64: csum: Fix OoB access in IP checksum code<br /> for negative lengths") fixes the same issue on ARM64.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: check vxlan_vnigroup_init() return value<br /> <br /> vxlan_init() must check vxlan_vnigroup_init() success<br /> otherwise a crash happens later, spotted by syzbot.<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167]<br /> CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912<br /> Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00<br /> RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb<br /> RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18<br /> RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000<br /> R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000<br /> FS: 00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942<br /> unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824<br /> unregister_netdevice_many net/core/dev.c:11866 [inline]<br /> unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736<br /> register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901<br /> __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981<br /> vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407<br /> rtnl_newlink_create net/core/rtnetlink.c:3795 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3906 [inline]