Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: rndis_host: Secure rndis_query check against int overflow<br /> <br /> Variables off and len typed as uint32 in rndis_query function<br /> are controlled by incoming RNDIS response message thus their<br /> value may be manipulated. Setting off to a unexpectetly large<br /> value will cause the sum with len and 8 to overflow and pass<br /> the implemented validation step. Consequently the response<br /> pointer will be referring to a location past the expected<br /> buffer boundaries allowing information leakage e.g. via<br /> RNDIS_OID_802_3_PERMANENT_ADDRESS OID.

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 /> KVM: s390: pv: fix index value of replaced ASCE<br /> <br /> The index field of the struct page corresponding to a guest ASCE should<br /> be 0. When replacing the ASCE in s390_replace_asce(), the index of the<br /> new ASCE should also be set to 0.<br /> <br /> Having the wrong index might lead to the wrong addresses being passed<br /> around when notifying pte invalidations, and eventually to validity<br /> intercepts (VM crash) if the prefix gets unmapped and the notifier gets<br /> called with the wrong address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: anysee: fix null-ptr-deref in anysee_master_xfer<br /> <br /> In anysee_master_xfer, msg is controlled by user. When msg[i].buf<br /> is null and msg[i].len is zero, former checks on msg[i].buf would be<br /> passed. Malicious data finally reach anysee_master_xfer. If accessing<br /> msg[i].buf[0] without sanity check, null ptr deref would happen.<br /> We add check on msg[i].len to prevent crash.<br /> <br /> Similar commit:<br /> commit 0ed554fd769a<br /> ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")<br /> <br /> [hverkuil: add spaces around +]

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.