Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: prevent skb corruption on frag list segmentation<br /> <br /> Ian reported several skb corruptions triggered by rx-gro-list,<br /> collecting different oops alike:<br /> <br /> [ 62.624003] BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> [ 62.631083] #PF: supervisor read access in kernel mode<br /> [ 62.636312] #PF: error_code(0x0000) - not-present page<br /> [ 62.641541] PGD 0 P4D 0<br /> [ 62.644174] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 62.648629] CPU: 1 PID: 913 Comm: napi/eno2-79 Not tainted 6.4.0 #364<br /> [ 62.655162] Hardware name: Supermicro Super Server/A2SDi-12C-HLN4F, BIOS 1.7a 10/13/2022<br /> [ 62.663344] RIP: 0010:__udp_gso_segment (./include/linux/skbuff.h:2858<br /> ./include/linux/udp.h:23 net/ipv4/udp_offload.c:228 net/ipv4/udp_offload.c:261<br /> net/ipv4/udp_offload.c:277)<br /> [ 62.687193] RSP: 0018:ffffbd3a83b4f868 EFLAGS: 00010246<br /> [ 62.692515] RAX: 00000000000000ce RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 62.699743] RDX: ffffa124def8a000 RSI: 0000000000000079 RDI: ffffa125952a14d4<br /> [ 62.706970] RBP: ffffa124def8a000 R08: 0000000000000022 R09: 00002000001558c9<br /> [ 62.714199] R10: 0000000000000000 R11: 00000000be554639 R12: 00000000000000e2<br /> [ 62.721426] R13: ffffa125952a1400 R14: ffffa125952a1400 R15: 00002000001558c9<br /> [ 62.728654] FS: 0000000000000000(0000) GS:ffffa127efa40000(0000)<br /> knlGS:0000000000000000<br /> [ 62.736852] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 62.742702] CR2: 00000000000000c0 CR3: 00000001034b0000 CR4: 00000000003526e0<br /> [ 62.749948] Call Trace:<br /> [ 62.752498] <br /> [ 62.779267] inet_gso_segment (net/ipv4/af_inet.c:1398)<br /> [ 62.787605] skb_mac_gso_segment (net/core/gro.c:141)<br /> [ 62.791906] __skb_gso_segment (net/core/dev.c:3403 (discriminator 2))<br /> [ 62.800492] validate_xmit_skb (./include/linux/netdevice.h:4862<br /> net/core/dev.c:3659)<br /> [ 62.804695] validate_xmit_skb_list (net/core/dev.c:3710)<br /> [ 62.809158] sch_direct_xmit (net/sched/sch_generic.c:330)<br /> [ 62.813198] __dev_queue_xmit (net/core/dev.c:3805 net/core/dev.c:4210)<br /> net/netfilter/core.c:626)<br /> [ 62.821093] br_dev_queue_push_xmit (net/bridge/br_forward.c:55)<br /> [ 62.825652] maybe_deliver (net/bridge/br_forward.c:193)<br /> [ 62.829420] br_flood (net/bridge/br_forward.c:233)<br /> [ 62.832758] br_handle_frame_finish (net/bridge/br_input.c:215)<br /> [ 62.837403] br_handle_frame (net/bridge/br_input.c:298<br /> net/bridge/br_input.c:416)<br /> [ 62.851417] __netif_receive_skb_core.constprop.0 (net/core/dev.c:5387)<br /> [ 62.866114] __netif_receive_skb_list_core (net/core/dev.c:5570)<br /> [ 62.871367] netif_receive_skb_list_internal (net/core/dev.c:5638<br /> net/core/dev.c:5727)<br /> [ 62.876795] napi_complete_done (./include/linux/list.h:37<br /> ./include/net/gro.h:434 ./include/net/gro.h:429 net/core/dev.c:6067)<br /> [ 62.881004] ixgbe_poll (drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:3191)<br /> [ 62.893534] __napi_poll (net/core/dev.c:6498)<br /> [ 62.897133] napi_threaded_poll (./include/linux/netpoll.h:89<br /> net/core/dev.c:6640)<br /> [ 62.905276] kthread (kernel/kthread.c:379)<br /> [ 62.913435] ret_from_fork (arch/x86/entry/entry_64.S:314)<br /> [ 62.917119] <br /> <br /> In the critical scenario, rx-gro-list GRO-ed packets are fed, via a<br /> bridge, both to the local input path and to an egress device (tun).<br /> <br /> The segmentation of such packets unsafely writes to the cloned skbs<br /> with shared heads.<br /> <br /> This change addresses the issue by uncloning as needed the<br /> to-be-segmented skbs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/iommu: Fix notifiers being shared by PCI and VIO buses<br /> <br /> fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both<br /> PCI and VIO buses. struct notifier_block is a linked list node, so this<br /> causes any notifiers later registered to either bus type to also be<br /> registered to the other since they share the same node.<br /> <br /> This causes issues in (at least) the vgaarb code, which registers a<br /> notifier for PCI buses. pci_notify() ends up being called on a vio<br /> device, converted with to_pci_dev() even though it&amp;#39;s not a PCI device,<br /> and finally makes a bad access in vga_arbiter_add_pci_device() as<br /> discovered with KASAN:<br /> <br /> BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00<br /> Read of size 4 at addr c000000264c26fdc by task swapper/0/1<br /> <br /> Call Trace:<br /> dump_stack_lvl+0x1bc/0x2b8 (unreliable)<br /> print_report+0x3f4/0xc60<br /> kasan_report+0x244/0x698<br /> __asan_load4+0xe8/0x250<br /> vga_arbiter_add_pci_device+0x60/0xe00<br /> pci_notify+0x88/0x444<br /> notifier_call_chain+0x104/0x320<br /> blocking_notifier_call_chain+0xa0/0x140<br /> device_add+0xac8/0x1d30<br /> device_register+0x58/0x80<br /> vio_register_device_node+0x9ac/0xce0<br /> vio_bus_scan_register_devices+0xc4/0x13c<br /> __machine_initcall_pseries_vio_device_init+0x94/0xf0<br /> do_one_initcall+0x12c/0xaa8<br /> kernel_init_freeable+0xa48/0xba8<br /> kernel_init+0x64/0x400<br /> ret_from_kernel_thread+0x5c/0x64<br /> <br /> Fix this by creating separate notifier_block structs for each bus type.<br /> <br /> [mpe: Add #ifdef to fix CONFIG_IBMVIO=n build]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: fix enumeration completion<br /> <br /> The soundwire subsystem uses two completion structures that allow<br /> drivers to wait for soundwire device to become enumerated on the bus and<br /> initialised by their drivers, respectively.<br /> <br /> The code implementing the signalling is currently broken as it does not<br /> signal all current and future waiters and also uses the wrong<br /> reinitialisation function, which can potentially lead to memory<br /> corruption if there are still waiters on the queue.<br /> <br /> Not signalling future waiters specifically breaks sound card probe<br /> deferrals as codec drivers can not tell that the soundwire device is<br /> already attached when being reprobed. Some codec runtime PM<br /> implementations suffer from similar problems as waiting for enumeration<br /> during resume can also timeout despite the device already having been<br /> enumerated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: stm32-pwr: fix of_iomap leak<br /> <br /> Smatch reports:<br /> drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn:<br /> &amp;#39;base&amp;#39; from of_iomap() not released on lines: 151,166.<br /> <br /> In stm32_pwr_regulator_probe(), base is not released<br /> when devm_kzalloc() fails to allocate memory or<br /> devm_regulator_register() fails to register a new regulator device,<br /> which may cause a leak.<br /> <br /> To fix this issue, replace of_iomap() with<br /> devm_platform_ioremap_resource(). devm_platform_ioremap_resource()<br /> is a specialized function for platform devices.<br /> It allows &amp;#39;base&amp;#39; to be automatically released whether the probe<br /> function succeeds or fails.<br /> <br /> Besides, use IS_ERR(base) instead of !base<br /> as the return value of devm_platform_ioremap_resource()<br /> can either be a pointer to the remapped memory or<br /> an ERR_PTR() encoded error code if the operation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gvt: fix gvt debugfs destroy<br /> <br /> When gvt debug fs is destroyed, need to have a sane check if drm<br /> minor&amp;#39;s debugfs root is still available or not, otherwise in case like<br /> device remove through unbinding, drm minor&amp;#39;s debugfs directory has<br /> already been removed, then intel_gvt_debugfs_clean() would act upon<br /> dangling pointer like below oops.<br /> <br /> i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x1926_rid_0x0a.golden_hw_state failed with error -2<br /> i915 0000:00:02.0: MDEV: Registered<br /> Console: switching to colour dummy device 80x25<br /> i915 0000:00:02.0: MDEV: Unregistering<br /> BUG: kernel NULL pointer dereference, address: 00000000000000a0<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 2486 Comm: gfx-unbind.sh Tainted: G I 6.1.0-rc8+ #15<br /> Hardware name: Dell Inc. XPS 13 9350/0JXC1H, BIOS 1.13.0 02/10/2020<br /> RIP: 0010:down_write+0x1f/0x90<br /> Code: 1d ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89 fb e8 62 c0 ff ff bf 01 00 00 00 e8 28 5e 31 ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 33 65 48 8b 04 25 c0 bd 01 00 48 89 43 08 bf 01<br /> RSP: 0018:ffff9eb3036ffcc8 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000000000a0 RCX: ffffff8100000000<br /> RDX: 0000000000000001 RSI: 0000000000000064 RDI: ffffffffa48787a8<br /> RBP: ffff9eb3036ffd30 R08: ffffeb1fc45a0608 R09: ffffeb1fc45a05c0<br /> R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff91acc33fa328 R14: ffff91acc033f080 R15: ffff91acced533e0<br /> FS: 00007f6947bba740(0000) GS:ffff91ae36d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000a0 CR3: 00000001133a2002 CR4: 00000000003706e0<br /> Call Trace:<br /> <br /> simple_recursive_removal+0x9f/0x2a0<br /> ? start_creating.part.0+0x120/0x120<br /> ? _raw_spin_lock+0x13/0x40<br /> debugfs_remove+0x40/0x60<br /> intel_gvt_debugfs_clean+0x15/0x30 [kvmgt]<br /> intel_gvt_clean_device+0x49/0xe0 [kvmgt]<br /> intel_gvt_driver_remove+0x2f/0xb0<br /> i915_driver_remove+0xa4/0xf0<br /> i915_pci_remove+0x1a/0x30<br /> pci_device_remove+0x33/0xa0<br /> device_release_driver_internal+0x1b2/0x230<br /> unbind_store+0xe0/0x110<br /> kernfs_fop_write_iter+0x11b/0x1f0<br /> vfs_write+0x203/0x3d0<br /> ksys_write+0x63/0xe0<br /> do_syscall_64+0x37/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f6947cb5190<br /> Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89<br /> RSP: 002b:00007ffcbac45a28 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f6947cb5190<br /> RDX: 000000000000000d RSI: 0000555e35c866a0 RDI: 0000000000000001<br /> RBP: 0000555e35c866a0 R08: 0000000000000002 R09: 0000555e358cb97c<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001<br /> R13: 000000000000000d R14: 0000000000000000 R15: 0000555e358cb8e0<br /> <br /> Modules linked in: kvmgt<br /> CR2: 00000000000000a0<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: Protect reconfiguration of sb read-write from racing writes<br /> <br /> The reconfigure / remount code takes a lot of effort to protect<br /> filesystem&amp;#39;s reconfiguration code from racing writes on remounting<br /> read-only. However during remounting read-only filesystem to read-write<br /> mode userspace writes can start immediately once we clear SB_RDONLY<br /> flag. This is inconvenient for example for ext4 because we need to do<br /> some writes to the filesystem (such as preparation of quota files)<br /> before we can take userspace writes so we are clearing SB_RDONLY flag<br /> before we are fully ready to accept userpace writes and syzbot has found<br /> a way to exploit this [1]. Also as far as I&amp;#39;m reading the code<br /> the filesystem remount code was protected from racing writes in the<br /> legacy mount path by the mount&amp;#39;s MNT_READONLY flag so this is relatively<br /> new problem. It is actually fairly easy to protect remount read-write<br /> from racing writes using sb-&gt;s_readonly_remount flag so let&amp;#39;s just do<br /> that instead of having to workaround these races in the filesystem code.<br /> <br /> [1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedi: Fix use after free bug in qedi_remove()<br /> <br /> In qedi_probe() we call __qedi_probe() which initializes<br /> &amp;qedi-&gt;recovery_work with qedi_recovery_handler() and<br /> &amp;qedi-&gt;board_disable_work with qedi_board_disable_work().<br /> <br /> When qedi_schedule_recovery_handler() is called, schedule_delayed_work()<br /> will finally start the work.<br /> <br /> In qedi_remove(), which is called to remove the driver, the following<br /> sequence may be observed:<br /> <br /> Fix this by finishing the work before cleanup in qedi_remove().<br /> <br /> CPU0 CPU1<br /> <br /> |qedi_recovery_handler<br /> qedi_remove |<br /> __qedi_remove |<br /> iscsi_host_free |<br /> scsi_host_put |<br /> //free shost |<br /> |iscsi_host_for_each_session<br /> |//use qedi-&gt;shost<br /> <br /> Cancel recovery_work and board_disable_work in __qedi_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver: soc: xilinx: use _safe loop iterator to avoid a use after free<br /> <br /> The hash_for_each_possible() loop dereferences "eve_data" to get the<br /> next item on the list. However the loop frees eve_data so it leads to<br /> a use after free. Use hash_for_each_possible_safe() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix null-ptr-deref in unix_stream_sendpage().<br /> <br /> Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage()<br /> with detailed analysis and a nice repro.<br /> <br /> unix_stream_sendpage() tries to add data to the last skb in the peer&amp;#39;s<br /> recv queue without locking the queue.<br /> <br /> If the peer&amp;#39;s FD is passed to another socket and the socket&amp;#39;s FD is<br /> passed to the peer, there is a loop between them. If we close both<br /> sockets without receiving FD, the sockets will be cleaned up by garbage<br /> collection.<br /> <br /> The garbage collection iterates such sockets and unlinks skb with<br /> FD from the socket&amp;#39;s receive queue under the queue&amp;#39;s lock.<br /> <br /> So, there is a race where unix_stream_sendpage() could access an skb<br /> locklessly that is being released by garbage collection, resulting in<br /> use-after-free.<br /> <br /> To avoid the issue, unix_stream_sendpage() must lock the peer&amp;#39;s recv<br /> queue.<br /> <br /> Note the issue does not exist in 6.5+ thanks to the recent sendpage()<br /> refactoring.<br /> <br /> This patch is originally written by Linus Torvalds.<br /> <br /> BUG: unable to handle page fault for address: ffff988004dd6870<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> PREEMPT SMP PTI<br /> CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #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:kmem_cache_alloc_node+0xa2/0x1e0<br /> Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44<br /> RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246<br /> RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284<br /> RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0<br /> RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00<br /> R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8<br /> FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x1a/0x1f<br /> ? page_fault_oops+0xa9/0x1e0<br /> ? fixup_exception+0x1d/0x310<br /> ? exc_page_fault+0xa8/0x150<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? kmem_cache_alloc_node+0xa2/0x1e0<br /> ? __alloc_skb+0x16c/0x1e0<br /> __alloc_skb+0x16c/0x1e0<br /> alloc_skb_with_frags+0x48/0x1e0<br /> sock_alloc_send_pskb+0x234/0x270<br /> unix_stream_sendmsg+0x1f5/0x690<br /> sock_sendmsg+0x5d/0x60<br /> ____sys_sendmsg+0x210/0x260<br /> ___sys_sendmsg+0x83/0xd0<br /> ? kmem_cache_alloc+0xc6/0x1c0<br /> ? avc_disable+0x20/0x20<br /> ? percpu_counter_add_batch+0x53/0xc0<br /> ? alloc_empty_file+0x5d/0xb0<br /> ? alloc_file+0x91/0x170<br /> ? alloc_file_pseudo+0x94/0x100<br /> ? __fget_light+0x9f/0x120<br /> __sys_sendmsg+0x54/0xa0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x69/0xd3<br /> RIP: 0033:0x7f174d639a7d<br /> Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48<br /> RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d<br /> RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007<br /> RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff<br /> R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28<br /> R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: tegra: xusb: Clear the driver reference in usb-phy dev<br /> <br /> For the dual-role port, it will assign the phy dev to usb-phy dev and<br /> use the port dev driver as the dev driver of usb-phy.<br /> <br /> When we try to destroy the port dev, it will destroy its dev driver<br /> as well. But we did not remove the reference from usb-phy dev. This<br /> might cause the use-after-free issue in KASAN.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-digi00x: prevent potential use after free<br /> <br /> This code was supposed to return an error code if init_stream()<br /> failed, but it instead freed dg00x-&gt;rx_stream and returned success.<br /> This potentially leads to a use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix NULL pointer dereference on fastopen early fallback<br /> <br /> In case of early fallback to TCP, subflow_syn_recv_sock() deletes<br /> the subflow context before returning the newly allocated sock to<br /> the caller.<br /> <br /> The fastopen path does not cope with the above unconditionally<br /> dereferencing the subflow context.