Vulnerabilities

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 /> blk-cgroup: dropping parent refcount after pd_free_fn() is done<br /> <br /> Some cgroup policies will access parent pd through child pd even<br /> after pd_offline_fn() is done. If pd_free_fn() for parent is called<br /> before child, then UAF can be triggered. Hence it&amp;#39;s better to guarantee<br /> the order of pd_free_fn().<br /> <br /> Currently refcount of parent blkg is dropped in __blkg_release(), which<br /> is before pd_free_fn() is called in blkg_free_work_fn() while<br /> blkg_free_work_fn() is called asynchronously.<br /> <br /> This patch make sure pd_free_fn() called from removing cgroup is ordered<br /> by delaying dropping parent refcount after calling pd_free_fn() for<br /> child.<br /> <br /> BTW, pd_free_fn() will also be called from blkcg_deactivate_policy()<br /> from deleting device, and following patches will guarantee the order.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rcar_fdp1: Fix refcount leak in probe and remove function<br /> <br /> rcar_fcp_get() take reference, which should be balanced with<br /> rcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove and<br /> the error paths of fdp1_probe() to fix this.<br /> <br /> [hverkuil: resolve merge conflict, remove() is now void]

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.

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 ]---