Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment()<br /> <br /> As the call trace shows, skb_panic was caused by wrong skb-&gt;mac_header<br /> in nsh_gso_segment():<br /> <br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1<br /> RIP: 0010:skb_panic+0xda/0xe0<br /> call Trace:<br /> skb_push+0x91/0xa0<br /> nsh_gso_segment+0x4f3/0x570<br /> skb_mac_gso_segment+0x19e/0x270<br /> __skb_gso_segment+0x1e8/0x3c0<br /> validate_xmit_skb+0x452/0x890<br /> validate_xmit_skb_list+0x99/0xd0<br /> sch_direct_xmit+0x294/0x7c0<br /> __dev_queue_xmit+0x16f0/0x1d70<br /> packet_xmit+0x185/0x210<br /> packet_snd+0xc15/0x1170<br /> packet_sendmsg+0x7b/0xa0<br /> sock_sendmsg+0x14f/0x160<br /> <br /> The root cause is:<br /> nsh_gso_segment() use skb-&gt;network_header - nhoff to reset mac_header<br /> in skb_gso_error_unwind() if inner-layer protocol gso fails.<br /> However, skb-&gt;network_header may be reset by inner-layer protocol<br /> gso function e.g. mpls_gso_segment. skb-&gt;mac_header reset by the<br /> inaccurate network_header will be larger than skb headroom.<br /> <br /> nsh_gso_segment<br /> nhoff = skb-&gt;network_header - skb-&gt;mac_header;<br /> __skb_pull(skb,nsh_len)<br /> skb_mac_gso_segment<br /> mpls_gso_segment<br /> skb_reset_network_header(skb);//skb-&gt;network_header+=nsh_len<br /> return -EINVAL;<br /> skb_gso_error_unwind<br /> skb_push(skb, nsh_len);<br /> skb-&gt;mac_header = skb-&gt;network_header - nhoff;<br /> // skb-&gt;mac_header &gt; skb-&gt;headroom, cause skb_push panic<br /> <br /> Use correct mac_offset to restore mac_header and get rid of nhoff.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db()<br /> <br /> When nonstatic_release_resource_db() frees all resources associated<br /> with an PCMCIA socket, it forgets to free socket_data too, causing<br /> a memory leak observable with kmemleak:<br /> <br /> unreferenced object 0xc28d1000 (size 64):<br /> comm "systemd-udevd", pid 297, jiffies 4294898478 (age 194.484s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 f0 85 0e c3 00 00 00 00 ................<br /> 00 00 00 00 0c 10 8d c2 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x2d7/0x4a0<br /> [] kmalloc_trace+0x31/0xa4<br /> [] nonstatic_init+0x24/0x1a4 [pcmcia_rsrc]<br /> [] pcmcia_register_socket+0x200/0x35c [pcmcia_core]<br /> [] yenta_probe+0x4d8/0xa70 [yenta_socket]<br /> [] pci_device_probe+0x99/0x194<br /> [] really_probe+0x181/0x45c<br /> [] __driver_probe_device+0x75/0x1f4<br /> [] driver_probe_device+0x28/0xac<br /> [] __driver_attach+0xeb/0x1e4<br /> [] bus_for_each_dev+0x61/0xb4<br /> [] driver_attach+0x1e/0x28<br /> [] bus_add_driver+0x102/0x20c<br /> [] driver_register+0x5b/0x120<br /> [] __pci_register_driver+0x44/0x4c<br /> [] __UNIQUE_ID___addressable_cleanup_module188+0x1c/0xfffff000 [iTCO_vendor_support]<br /> <br /> Fix this by freeing socket_data too.<br /> <br /> Tested on a Acer Travelmate 4002WLMi by manually binding/unbinding<br /> the yenta_cardbus driver (yenta_socket).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/dcssblk: fix kernel crash with list_add corruption<br /> <br /> Commit fb08a1908cb1 ("dax: simplify the dax_device gendisk<br /> association") introduced new logic for gendisk association, requiring<br /> drivers to explicitly call dax_add_host() and dax_remove_host().<br /> <br /> For dcssblk driver, some dax_remove_host() calls were missing, e.g. in<br /> device remove path. The commit also broke error handling for out_dax case<br /> in device add path, resulting in an extra put_device() w/o the previous<br /> get_device() in that case.<br /> <br /> This lead to stale xarray entries after device add / remove cycles. In the<br /> case when a previously used struct gendisk pointer (xarray index) would be<br /> used again, because blk_alloc_disk() happened to return such a pointer, the<br /> xa_insert() in dax_add_host() would fail and go to out_dax, doing the extra<br /> put_device() in the error path. In combination with an already flawed error<br /> handling in dcssblk (device_register() cleanup), which needs to be<br /> addressed in a separate patch, this resulted in a missing device_del() /<br /> klist_del(), and eventually in the kernel crash with list_add corruption on<br /> a subsequent device_add() / klist_add().<br /> <br /> Fix this by adding the missing dax_remove_host() calls, and also move the<br /> put_device() in the error path to restore the previous logic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: sc16is7xx: setup GPIO controller later in probe<br /> <br /> The GPIO controller component of the sc16is7xx driver is setup too<br /> early, which can result in a race condition where another device tries<br /> to utilise the GPIO lines before the sc16is7xx device has finished<br /> initialising.<br /> <br /> This issue manifests itself as an Oops when the GPIO lines are configured:<br /> <br /> Unable to handle kernel read from unreadable memory at virtual address<br /> ...<br /> pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx]<br /> lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx]<br /> ...<br /> Call trace:<br /> sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx]<br /> gpiod_direction_output_raw_commit+0x64/0x318<br /> gpiod_direction_output+0xb0/0x170<br /> create_gpio_led+0xec/0x198<br /> gpio_led_probe+0x16c/0x4f0<br /> platform_drv_probe+0x5c/0xb0<br /> really_probe+0xe8/0x448<br /> driver_probe_device+0xe8/0x138<br /> __device_attach_driver+0x94/0x118<br /> bus_for_each_drv+0x8c/0xe0<br /> __device_attach+0x100/0x1b8<br /> device_initial_probe+0x28/0x38<br /> bus_probe_device+0xa4/0xb0<br /> deferred_probe_work_func+0x90/0xe0<br /> process_one_work+0x1c4/0x480<br /> worker_thread+0x54/0x430<br /> kthread+0x138/0x150<br /> ret_from_fork+0x10/0x1c<br /> <br /> This patch moves the setup of the GPIO controller functions to later in the<br /> probe function, ensuring the sc16is7xx device has already finished<br /> initialising by the time other devices try to make use of the GPIO lines.<br /> The error handling has also been reordered to reflect the new<br /> initialisation order.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inotify: Avoid reporting event with invalid wd<br /> <br /> When inotify_freeing_mark() races with inotify_handle_inode_event() it<br /> can happen that inotify_handle_inode_event() sees that i_mark-&gt;wd got<br /> already reset to -1 and reports this value to userspace which can<br /> confuse the inotify listener. Avoid the problem by validating that wd is<br /> sensible (and pretend the mark got removed before the event got<br /> generated otherwise).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-generic: prohibit potential out-of-bounds access<br /> <br /> The fbdev test of IGT may write after EOF, which lead to out-of-bound<br /> access for drm drivers with fbdev-generic. For example, run fbdev test<br /> on a x86+ast2400 platform, with 1680x1050 resolution, will cause the<br /> linux kernel hang with the following call trace:<br /> <br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> [IGT] fbdev: starting subtest eof<br /> Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]<br /> [IGT] fbdev: starting subtest nullptr<br /> <br /> RIP: 0010:memcpy_erms+0xa/0x20<br /> RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246<br /> RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0<br /> RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000<br /> RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0<br /> R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80<br /> R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30<br /> FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]<br /> drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]<br /> process_one_work+0x21f/0x430<br /> worker_thread+0x4e/0x3c0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xf4/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> CR2: ffffa17d40e0b000<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The is because damage rectangles computed by<br /> drm_fb_helper_memory_range_to_clip() function is not guaranteed to be<br /> bound in the screen&amp;#39;s active display area. Possible reasons are:<br /> <br /> 1) Buffers are allocated in the granularity of page size, for mmap system<br /> call support. The shadow screen buffer consumed by fbdev emulation may<br /> also choosed be page size aligned.<br /> <br /> 2) The DIV_ROUND_UP() used in drm_fb_helper_memory_range_to_clip()<br /> will introduce off-by-one error.<br /> <br /> For example, on a 16KB page size system, in order to store a 1920x1080<br /> XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size<br /> 1920*1080*4 can not be divided exactly by 16KB.<br /> <br /> 1920 * 1080 * 4 = 8294400 bytes<br /> 506 * 16 * 1024 = 8290304 bytes<br /> 507 * 16 * 1024 = 8306688 bytes<br /> <br /> line_length = 1920*4 = 7680 bytes<br /> <br /> 507 * 16 * 1024 / 7680 = 1081.6<br /> <br /> off / line_length = 507 * 16 * 1024 / 7680 = 1081<br /> DIV_ROUND_UP(507 * 16 * 1024, 7680) will yeild 1082<br /> <br /> memcpy_toio() typically issue the copy line by line, when copy the last<br /> line, out-of-bound access will be happen. Because:<br /> <br /> 1082 * line_length = 1082 * 7680 = 8309760, and 8309760 &gt; 8306688<br /> <br /> Note that userspace may still write to the invisiable area if a larger<br /> buffer than width x stride is exposed. But it is not a big issue as<br /> long as there still have memory resolve the access if not drafting so<br /> far.<br /> <br /> - Also limit the y1 (Daniel)<br /> - keep fix patch it to minimal (Daniel)<br /> - screen_size is page size aligned because of it need mmap (Thomas)<br /> - Adding fixes tag (Thomas)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix race condition in hidp_session_thread<br /> <br /> There is a potential race condition in hidp_session_thread that may<br /> lead to use-after-free. For instance, the timer is active while<br /> hidp_del_timer is called in hidp_session_thread(). After hidp_session_put,<br /> then &amp;#39;session&amp;#39; will be freed, causing kernel panic when hidp_idle_timeout<br /> is running.<br /> <br /> The solution is to use del_timer_sync instead of del_timer.<br /> <br /> Here is the call trace:<br /> <br /> ? hidp_session_probe+0x780/0x780<br /> call_timer_fn+0x2d/0x1e0<br /> __run_timers.part.0+0x569/0x940<br /> hidp_session_probe+0x780/0x780<br /> call_timer_fn+0x1e0/0x1e0<br /> ktime_get+0x5c/0xf0<br /> lapic_next_deadline+0x2c/0x40<br /> clockevents_program_event+0x205/0x320<br /> run_timer_softirq+0xa9/0x1b0<br /> __do_softirq+0x1b9/0x641<br /> __irq_exit_rcu+0xdc/0x190<br /> irq_exit_rcu+0xe/0x20<br /> sysvec_apic_timer_interrupt+0xa1/0xc0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow<br /> <br /> A static code analysis tool flagged the possibility of buffer overflow when<br /> using copy_from_user() for a debugfs entry.<br /> <br /> Currently, it is possible that copy_from_user() copies more bytes than what<br /> would fit in the mybuf char array. Add a min() restriction check between<br /> sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect<br /> against buffer overflow.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: isotp: check CAN address family in isotp_bind()<br /> <br /> Add missing check to block non-AF_CAN binds.<br /> <br /> Syzbot created some code which matched the right sockaddr struct size<br /> but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family<br /> field:<br /> <br /> bind$xdp(r2, &amp;(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10)<br /> ^^^^<br /> This has no funtional impact but the userspace should be notified about<br /> the wrong address family field content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: fix potential memory leak in mlx5e_init_rep_rx<br /> <br /> The memory pointed to by the priv-&gt;rx_res pointer is not freed in the error<br /> path of mlx5e_init_rep_rx, which can lead to a memory leak. Fix by freeing<br /> the memory in the error path, thereby making the error path identical to<br /> mlx5e_cleanup_rep_rx().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix DMA-API call trace on NVMe LS requests<br /> <br /> The following message and call trace was seen with debug kernels:<br /> <br /> DMA-API: qla2xxx 0000:41:00.0: device driver failed to check map<br /> error [device address=0x00000002a3ff38d8] [size=1024 bytes] [mapped as<br /> single]<br /> WARNING: CPU: 0 PID: 2930 at kernel/dma/debug.c:1017<br /> check_unmap+0xf42/0x1990<br /> <br /> Call Trace:<br /> debug_dma_unmap_page+0xc9/0x100<br /> qla_nvme_ls_unmap+0x141/0x210 [qla2xxx]<br /> <br /> Remove DMA mapping from the driver altogether, as it is already done by FC<br /> layer. This prevents the warning.