Vulnerabilities

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]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: hub: Ignore non-compliant devices with too many configs or interfaces<br /> <br /> Robert Morris created a test program which can cause<br /> usb_hub_to_struct_hub() to dereference a NULL or inappropriate<br /> pointer:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI<br /> CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14<br /> Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110<br /> ...<br /> Call Trace:<br /> <br /> ? die_addr+0x31/0x80<br /> ? exc_general_protection+0x1b4/0x3c0<br /> ? asm_exc_general_protection+0x26/0x30<br /> ? usb_hub_adjust_deviceremovable+0x78/0x110<br /> hub_probe+0x7c7/0xab0<br /> usb_probe_interface+0x14b/0x350<br /> really_probe+0xd0/0x2d0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> __driver_probe_device+0x6e/0x110<br /> driver_probe_device+0x1a/0x90<br /> __device_attach_driver+0x7e/0xc0<br /> bus_for_each_drv+0x7f/0xd0<br /> __device_attach+0xaa/0x1a0<br /> bus_probe_device+0x8b/0xa0<br /> device_add+0x62e/0x810<br /> usb_set_configuration+0x65d/0x990<br /> usb_generic_driver_probe+0x4b/0x70<br /> usb_probe_device+0x36/0xd0<br /> <br /> The cause of this error is that the device has two interfaces, and the<br /> hub driver binds to interface 1 instead of interface 0, which is where<br /> usb_hub_to_struct_hub() looks.<br /> <br /> We can prevent the problem from occurring by refusing to accept hub<br /> devices that violate the USB spec by having more than one<br /> configuration or interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: fix panic during interface removal<br /> <br /> Reference counting is used to ensure that<br /> batadv_hardif_neigh_node and batadv_hard_iface<br /> are not freed before/during<br /> batadv_v_elp_throughput_metric_update work is<br /> finished.<br /> <br /> But there isn&amp;#39;t a guarantee that the hard if will<br /> remain associated with a soft interface up until<br /> the work is finished.<br /> <br /> This fixes a crash triggered by reboot that looks<br /> like this:<br /> <br /> Call trace:<br /> batadv_v_mesh_free+0xd0/0x4dc [batman_adv]<br /> batadv_v_elp_throughput_metric_update+0x1c/0xa4<br /> process_one_work+0x178/0x398<br /> worker_thread+0x2e8/0x4d0<br /> kthread+0xd8/0xdc<br /> ret_from_fork+0x10/0x20<br /> <br /> (the batadv_v_mesh_free call is misleading,<br /> and does not actually happen)<br /> <br /> I was able to make the issue happen more reliably<br /> by changing hardif_neigh-&gt;bat_v.metric_work work<br /> to be delayed work. This allowed me to track down<br /> and confirm the fix.<br /> <br /> [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without<br /> soft_iface]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Validate the persistent meta data subbuf array<br /> <br /> The meta data for a mapped ring buffer contains an array of indexes of all<br /> the subbuffers. The first entry is the reader page, and the rest of the<br /> entries lay out the order of the subbuffers in how the ring buffer link<br /> list is to be created.<br /> <br /> The validator currently makes sure that all the entries are within the<br /> range of 0 and nr_subbufs. But it does not check if there are any<br /> duplicates.<br /> <br /> While working on the ring buffer, I corrupted this array, where I added<br /> duplicates. The validator did not catch it and created the ring buffer<br /> link list on top of it. Luckily, the corruption was only that the reader<br /> page was also in the writer path and only presented corrupted data but did<br /> not crash the kernel. But if there were duplicates in the writer side,<br /> then it could corrupt the ring buffer link list and cause a crash.<br /> <br /> Create a bitmask array with the size of the number of subbuffers. Then<br /> clear it. When walking through the subbuf array checking to see if the<br /> entries are within the range, test if its bit is already set in the<br /> subbuf_mask. If it is, then there is duplicates and fail the validation.<br /> If not, set the corresponding bit and continue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Do not allow mmap() of persistent ring buffer<br /> <br /> When trying to mmap a trace instance buffer that is attached to<br /> reserve_mem, it would crash:<br /> <br /> BUG: unable to handle page fault for address: ffffe97bd00025c8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 2862f3067 P4D 2862f3067 PUD 0<br /> Oops: Oops: 0000 [#1] PREEMPT_RT SMP PTI<br /> CPU: 4 UID: 0 PID: 981 Comm: mmap-rb Not tainted 6.14.0-rc2-test-00003-g7f1a5e3fbf9e-dirty #233<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:validate_page_before_insert+0x5/0xb0<br /> Code: e2 01 89 d0 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 46 08 a8 01 75 67 66 90 48 89 f0 8b 50 34 85 d2 74 76 48 89<br /> RSP: 0018:ffffb148c2f3f968 EFLAGS: 00010246<br /> RAX: ffff9fa5d3322000 RBX: ffff9fa5ccff9c08 RCX: 00000000b879ed29<br /> RDX: ffffe97bd00025c0 RSI: ffffe97bd00025c0 RDI: ffff9fa5ccff9c08<br /> RBP: ffffb148c2f3f9f0 R08: 0000000000000004 R09: 0000000000000004<br /> R10: 0000000000000000 R11: 0000000000000200 R12: 0000000000000000<br /> R13: 00007f16a18d5000 R14: ffff9fa5c48db6a8 R15: 0000000000000000<br /> FS: 00007f16a1b54740(0000) GS:ffff9fa73df00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffe97bd00025c8 CR3: 00000001048c6006 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x1f<br /> ? __die+0x2e/0x40<br /> ? page_fault_oops+0x157/0x2b0<br /> ? search_module_extables+0x53/0x80<br /> ? validate_page_before_insert+0x5/0xb0<br /> ? kernelmode_fixup_or_oops.isra.0+0x5f/0x70<br /> ? __bad_area_nosemaphore+0x16e/0x1b0<br /> ? bad_area_nosemaphore+0x16/0x20<br /> ? do_kern_addr_fault+0x77/0x90<br /> ? exc_page_fault+0x22b/0x230<br /> ? asm_exc_page_fault+0x2b/0x30<br /> ? validate_page_before_insert+0x5/0xb0<br /> ? vm_insert_pages+0x151/0x400<br /> __rb_map_vma+0x21f/0x3f0<br /> ring_buffer_map+0x21b/0x2f0<br /> tracing_buffers_mmap+0x70/0xd0<br /> __mmap_region+0x6f0/0xbd0<br /> mmap_region+0x7f/0x130<br /> do_mmap+0x475/0x610<br /> vm_mmap_pgoff+0xf2/0x1d0<br /> ksys_mmap_pgoff+0x166/0x200<br /> __x64_sys_mmap+0x37/0x50<br /> x64_sys_call+0x1670/0x1d70<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The reason was that the code that maps the ring buffer pages to user space<br /> has:<br /> <br /> page = virt_to_page((void *)cpu_buffer-&gt;subbuf_ids[s]);<br /> <br /> And uses that in:<br /> <br /> vm_insert_pages(vma, vma-&gt;vm_start, pages, &amp;nr_pages);<br /> <br /> But virt_to_page() does not work with vmap()&amp;#39;d memory which is what the<br /> persistent ring buffer has. It is rather trivial to allow this, but for<br /> now just disable mmap() of instances that have their ring buffer from the<br /> reserve_mem option.<br /> <br /> If an mmap() is performed on a persistent buffer it will return -ENODEV<br /> just like it would if the .mmap field wasn&amp;#39;t defined in the<br /> file_operations structure.