Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()<br /> <br /> If ipi_send_{mask|single}() is called with an invalid interrupt number, all<br /> the local variables there will be NULL. ipi_send_verify() which is invoked<br /> from these functions does verify its &amp;#39;data&amp;#39; parameter, resulting in a<br /> kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets<br /> dereferenced.<br /> <br /> Add a missing NULL pointer check in ipi_send_verify()...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one<br /> <br /> Eric Dumazet says:<br /> nf_conntrack_dccp_packet() has an unique:<br /> <br /> dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &amp;_dh);<br /> <br /> And nothing more is &amp;#39;pulled&amp;#39; from the packet, depending on the content.<br /> dh-&gt;dccph_doff, and/or dh-&gt;dccph_x ...)<br /> So dccp_ack_seq() is happily reading stuff past the _dh buffer.<br /> <br /> BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0<br /> Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371<br /> [..]<br /> <br /> Fix this by increasing the stack buffer to also include room for<br /> the extra sequence numbers and all the known dccp packet type headers,<br /> then pull again after the initial validation of the basic header.<br /> <br /> While at it, mark packets invalid that lack 48bit sequence bit but<br /> where RFC says the type MUST use them.<br /> <br /> Compile tested only.<br /> <br /> v2: first skb_header_pointer() now needs to adjust the size to<br /> only pull the generic header. (Eric)<br /> <br /> Heads-up: I intend to remove dccp conntrack support later this year.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: chipidea: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()<br /> <br /> The function mpi3mr_get_all_tgt_info() has four issues:<br /> <br /> 1) It calculates valid entry length in alltgt_info assuming the header part<br /> of the struct mpi3mr_device_map_info would equal to sizeof(u32). The<br /> correct size is sizeof(u64).<br /> <br /> 2) When it calculates the valid entry length kern_entrylen, it excludes one<br /> entry by subtracting 1 from num_devices.<br /> <br /> 3) It copies num_device by calling memcpy(). Substitution is enough.<br /> <br /> 4) It does not specify the calculated length to sg_copy_from_buffer().<br /> Instead, it specifies the payload length which is larger than the<br /> alltgt_info size. It causes "BUG: KASAN: slab-out-of-bounds".<br /> <br /> Fix the issues by using the correct header size, removing the subtraction<br /> from num_devices, replacing the memcpy() with substitution and specifying<br /> the correct length to sg_copy_from_buffer().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211_hwsim: drop short frames<br /> <br /> While technically some control frames like ACK are shorter and<br /> end after Address 1, such frames shouldn&amp;#39;t be forwarded through<br /> wmediumd or similar userspace, so require the full 3-address<br /> header to avoid accessing invalid memory if shorter frames are<br /> passed in.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Wait for io return on terminate rport<br /> <br /> System crash due to use after free.<br /> Current code allows terminate_rport_io to exit before making<br /> sure all IOs has returned. For FCP-2 device, IO&amp;#39;s can hang<br /> on in HW because driver has not tear down the session in FW at<br /> first sign of cable pull. When dev_loss_tmo timer pops,<br /> terminate_rport_io is called and upper layer is about to<br /> free various resources. Terminate_rport_io trigger qla to do<br /> the final cleanup, but the cleanup might not be fast enough where it<br /> leave qla still holding on to the same resource.<br /> <br /> Wait for IO&amp;#39;s to return to upper layer before resources are freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext2/dax: Fix ext2_setsize when len is page aligned<br /> <br /> PAGE_ALIGN(x) macro gives the next highest value which is multiple of<br /> pagesize. But if x is already page aligned then it simply returns x.<br /> So, if x passed is 0 in dax_zero_range() function, that means the<br /> length gets passed as 0 to -&gt;iomap_begin().<br /> <br /> In ext2 it then calls ext2_get_blocks -&gt; max_blocks as 0 and hits bug_on<br /> here in ext2_get_blocks().<br /> BUG_ON(maxblocks == 0);<br /> <br /> Instead we should be calling dax_truncate_page() here which takes<br /> care of it. i.e. it only calls dax_zero_range if the offset is not<br /> page/block aligned.<br /> <br /> This can be easily triggered with following on fsdax mounted pmem<br /> device.<br /> <br /> dd if=/dev/zero of=file count=1 bs=512<br /> truncate -s 0 file<br /> <br /> [79.525838] EXT2-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk<br /> [79.529376] ext2 filesystem being mounted at /mnt1/test supports timestamps until 2038 (0x7fffffff)<br /> [93.793207] ------------[ cut here ]------------<br /> [93.795102] kernel BUG at fs/ext2/inode.c:637!<br /> [93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [93.798659] CPU: 0 PID: 1192 Comm: truncate Not tainted 6.3.0-rc2-xfstests-00056-g131086faa369 #139<br /> [93.806459] RIP: 0010:ext2_get_blocks.constprop.0+0x524/0x610<br /> <br /> [93.835298] Call Trace:<br /> [93.836253] <br /> [93.837103] ? lock_acquire+0xf8/0x110<br /> [93.838479] ? d_lookup+0x69/0xd0<br /> [93.839779] ext2_iomap_begin+0xa7/0x1c0<br /> [93.841154] iomap_iter+0xc7/0x150<br /> [93.842425] dax_zero_range+0x6e/0xa0<br /> [93.843813] ext2_setsize+0x176/0x1b0<br /> [93.845164] ext2_setattr+0x151/0x200<br /> [93.846467] notify_change+0x341/0x4e0<br /> [93.847805] ? lock_acquire+0xf8/0x110<br /> [93.849143] ? do_truncate+0x74/0xe0<br /> [93.850452] ? do_truncate+0x84/0xe0<br /> [93.851739] do_truncate+0x84/0xe0<br /> [93.852974] do_sys_ftruncate+0x2b4/0x2f0<br /> [93.854404] do_syscall_64+0x3f/0x90<br /> [93.855789] entry_SYSCALL_64_after_hwframe+0x72/0xdc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp5: Don&amp;#39;t leak some plane state<br /> <br /> Apparently no one noticed that mdp5 plane states leak like a sieve<br /> ever since we introduced plane_state-&gt;commit refcount a few years ago<br /> in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too<br /> early by tracking commits, v3.")<br /> <br /> Fix it by using the right helpers.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/551236/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer()<br /> <br /> Change logging from drm_{err,info}() to dev_{err,info}() in functions<br /> mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be<br /> essential to avoid getting NULL pointer kernel panics if any kind<br /> of error happens during AUX transfers happening before the bridge<br /> is attached.<br /> <br /> This may potentially start happening in a later commit implementing<br /> aux-bus support, as AUX transfers will be triggered from the panel<br /> driver (for EDID) before the mtk-dp bridge gets attached, and it&amp;#39;s<br /> done in preparation for the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc: Don&amp;#39;t try to copy PPR for task with NULL pt_regs<br /> <br /> powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which<br /> from my (arguably very short) checking is not commonly done for other<br /> archs. This is fine, except when PF_IO_WORKER&amp;#39;s have been created and<br /> the task does something that causes a coredump to be generated. Then we<br /> get this crash:<br /> <br /> Kernel attempted to read user page (160) - exploit attempt? (uid: 1000)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000160<br /> Faulting instruction address: 0xc0000000000c3a60<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries<br /> Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod<br /> CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88<br /> Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries<br /> NIP: c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0<br /> REGS: c0000000041833b0 TRAP: 0300 Not tainted (6.3.0-rc2+)<br /> MSR: 800000000280b033 CR: 88082828 XER: 200400f8<br /> ...<br /> NIP memcpy_power7+0x200/0x7d0<br /> LR ppr_get+0x64/0xb0<br /> Call Trace:<br /> ppr_get+0x40/0xb0 (unreliable)<br /> __regset_get+0x180/0x1f0<br /> regset_get_alloc+0x64/0x90<br /> elf_core_dump+0xb98/0x1b60<br /> do_coredump+0x1c34/0x24a0<br /> get_signal+0x71c/0x1410<br /> do_notify_resume+0x140/0x6f0<br /> interrupt_exit_user_prepare_main+0x29c/0x320<br /> interrupt_exit_user_prepare+0x6c/0xa0<br /> interrupt_return_srr_user+0x8/0x138<br /> <br /> Because ppr_get() is trying to copy from a PF_IO_WORKER with a NULL<br /> pt_regs.<br /> <br /> Check for a valid pt_regs in both ppc_get/ppr_set, and return an error<br /> if not set. The actual error value doesn&amp;#39;t seem to be important here, so<br /> just pick -EINVAL.<br /> <br /> [mpe: Trim oops in change log, add Fixes &amp; Cc stable]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd/selftest: Catch overflow of uptr and length<br /> <br /> syzkaller hits a WARN_ON when trying to have a uptr close to UINTPTR_MAX:<br /> <br /> WARNING: CPU: 1 PID: 393 at drivers/iommu/iommufd/selftest.c:403 iommufd_test+0xb19/0x16f0<br /> Modules linked in:<br /> CPU: 1 PID: 393 Comm: repro Not tainted 6.2.0-c9c3395d5e3d #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:iommufd_test+0xb19/0x16f0<br /> Code: 94 c4 31 ff 44 89 e6 e8 a5 54 17 ff 45 84 e4 0f 85 bb 0b 00 00 41 be fb ff ff ff e8 31 53 17 ff e9 a0 f7 ff ff e8 27 53 17 ff 0b 41 be 8<br /> RSP: 0018:ffffc90000eabdc0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8214c487<br /> RDX: 0000000000000000 RSI: ffff88800f5c8000 RDI: 0000000000000002<br /> RBP: ffffc90000eabe48 R08: 0000000000000000 R09: 0000000000000001<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 00000000cd2b0000<br /> R13: 00000000cd2af000 R14: 0000000000000000 R15: ffffc90000eabe68<br /> FS: 00007f94d76d5740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000043 CR3: 0000000006880006 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? write_comp_data+0x2f/0x90<br /> iommufd_fops_ioctl+0x1ef/0x310<br /> __x64_sys_ioctl+0x10e/0x160<br /> ? __pfx_iommufd_fops_ioctl+0x10/0x10<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Check that the user memory range doesn&amp;#39;t overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix net_dev_start_xmit trace event vs skb_transport_offset()<br /> <br /> After blamed commit, we must be more careful about using<br /> skb_transport_offset(), as reminded us by syzbot:<br /> <br /> WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline]<br /> WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14<br /> Modules linked in:<br /> CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023<br /> Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet<br /> RIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline]<br /> RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline]<br /> RIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14<br /> Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff<br /> RSP: 0018:ffffc900002bf700 EFLAGS: 00010293<br /> RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280<br /> RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff<br /> RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e<br /> R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67<br /> R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> [] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline]<br /> [] xmit_one net/core/dev.c:3643 [inline]<br /> [] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660<br /> [] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324<br /> [] dev_queue_xmit include/linux/netdevice.h:3030 [inline]<br /> [] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108<br /> [] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127<br /> [] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline]<br /> [] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline]<br /> [] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701<br /> [] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289<br /> [] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436