Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix race condition when gathering fdinfo group samples<br /> <br /> Commit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to<br /> protect access to groups with an xarray lock, which could lead to<br /> use-after-free errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init<br /> <br /> devm_kasprintf() calls can return null pointers on failure.<br /> But some return values were not checked in zynqmp_audio_init().<br /> <br /> Add NULL check in zynqmp_audio_init(), avoid referencing null<br /> pointers in the subsequent code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()<br /> <br /> Instead of attempting the same mutex twice, lock and unlock it.<br /> <br /> This bug has been detected by the Clang thread-safety analyzer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()<br /> <br /> There are actually 2 problems:<br /> - deleting the last element doesn&amp;#39;t require the memmove of elements<br /> [i + 1, end) over it. Actually, element i+1 is out of bounds.<br /> - The memmove itself should move size - i - 1 elements, because the last<br /> element is out of bounds.<br /> <br /> The out-of-bounds element still remains out of bounds after being<br /> accessed, so the problem is only that we touch it, not that it becomes<br /> in active use. But I suppose it can lead to issues if the out-of-bounds<br /> element is part of an unmapped page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmxnet3: unregister xdp rxq info in the reset path<br /> <br /> vmxnet3 does not unregister xdp rxq info in the<br /> vmxnet3_reset_work() code path as vmxnet3_rq_destroy()<br /> is not invoked in this code path. So, we get below message with a<br /> backtrace.<br /> <br /> Missing unregister, handled but fix driver<br /> WARNING: CPU:48 PID: 500 at net/core/xdp.c:182<br /> __xdp_rxq_info_reg+0x93/0xf0<br /> <br /> This patch fixes the problem by moving the unregister<br /> code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: Use kernel helpers for hex dumps<br /> <br /> Previously, when the driver was printing hex dumps, the buffer was cast<br /> to an 8 byte long and printed using string formatters. If the buffer<br /> size was not a multiple of 8 then a read buffer overflow was possible.<br /> <br /> Therefore, create a new ibmvnic function that loops over a buffer and<br /> calls hex_dump_to_buffer instead.<br /> <br /> This patch address KASAN reports like the one below:<br /> ibmvnic 30000003 env3: Login Buffer:<br /> ibmvnic 30000003 env3: 01000000af000000<br /> <br /> ibmvnic 30000003 env3: 2e6d62692e736261<br /> ibmvnic 30000003 env3: 65050003006d6f63<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]<br /> Read of size 8 at addr c0000001331a9aa8 by task ip/17681<br /> <br /> Allocated by task 17681:<br /> <br /> ibmvnic_login+0x2f0/0xffc [ibmvnic]<br /> ibmvnic_open+0x148/0x308 [ibmvnic]<br /> __dev_open+0x1ac/0x304<br /> <br /> The buggy address is located 168 bytes inside of<br /> allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)<br /> <br /> =================================================================<br /> ibmvnic 30000003 env3: 000000000033766e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vkms: Fix use after free and double free on init error<br /> <br /> If the driver initialization fails, the vkms_exit() function might<br /> access an uninitialized or freed default_config pointer and it might<br /> double free it.<br /> <br /> Fix both possible errors by initializing default_config only when the<br /> driver initialization succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix NULL pointer dereference in l3mdev_l3_rcv<br /> <br /> When delete l3s ipvlan:<br /> <br /> ip link del link eth0 ipvlan1 type ipvlan mode l3s<br /> <br /> This may cause a null pointer dereference:<br /> <br /> Call trace:<br /> ip_rcv_finish+0x48/0xd0<br /> ip_rcv+0x5c/0x100<br /> __netif_receive_skb_one_core+0x64/0xb0<br /> __netif_receive_skb+0x20/0x80<br /> process_backlog+0xb4/0x204<br /> napi_poll+0xe8/0x294<br /> net_rx_action+0xd8/0x22c<br /> __do_softirq+0x12c/0x354<br /> <br /> This is because l3mdev_l3_rcv() visit dev-&gt;l3mdev_ops after<br /> ipvlan_l3s_unregister() assign the dev-&gt;l3mdev_ops to NULL. The process<br /> like this:<br /> <br /> (CPU1) | (CPU2)<br /> l3mdev_l3_rcv() |<br /> check dev-&gt;priv_flags: |<br /> master = skb-&gt;dev; |<br /> |<br /> | ipvlan_l3s_unregister()<br /> | set dev-&gt;priv_flags<br /> | dev-&gt;l3mdev_ops = NULL;<br /> |<br /> visit master-&gt;l3mdev_ops |<br /> <br /> To avoid this by do not set dev-&gt;l3mdev_ops when unregister l3s ipvlan.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: check xdp prog when set bond mode<br /> <br /> Following operations can trigger a warning[1]:<br /> <br /> ip netns add ns1<br /> ip netns exec ns1 ip link add bond0 type bond mode balance-rr<br /> ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp<br /> ip netns exec ns1 ip link set bond0 type bond mode broadcast<br /> ip netns del ns1<br /> <br /> When delete the namespace, dev_xdp_uninstall() is called to remove xdp<br /> program on bond dev, and bond_xdp_set() will check the bond mode. If bond<br /> mode is changed after attaching xdp program, the warning may occur.<br /> <br /> Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode<br /> with xdp program attached is not good. Add check for xdp program when set<br /> bond mode.<br /> <br /> [1]<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930<br /> Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ...<br /> RSP: 0018:ffffc90000063d80 EFLAGS: 00000282<br /> RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff<br /> RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48<br /> RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb<br /> R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8<br /> R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000<br /> FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> ? __warn+0x83/0x130<br /> ? unregister_netdevice_many_notify+0x8d9/0x930<br /> ? report_bug+0x18e/0x1a0<br /> ? handle_bug+0x54/0x90<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? unregister_netdevice_many_notify+0x8d9/0x930<br /> ? bond_net_exit_batch_rtnl+0x5c/0x90<br /> cleanup_net+0x237/0x3d0<br /> process_one_work+0x163/0x390<br /> worker_thread+0x293/0x3b0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xec/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2f/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/perf: Fix ref-counting on the PMU &amp;#39;vpa_pmu&amp;#39;<br /> <br /> Commit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa<br /> counters") introduced &amp;#39;vpa_pmu&amp;#39; to expose Book3s-HV nested APIv2 provided<br /> L1L2 context switch latency counters to L1 user-space via<br /> perf-events. However the newly introduced PMU named &amp;#39;vpa_pmu&amp;#39; doesn&amp;#39;t<br /> assign ownership of the PMU to the module &amp;#39;vpa_pmu&amp;#39;. Consequently the<br /> module &amp;#39;vpa_pmu&amp;#39; can be unloaded while one of the perf-events are still<br /> active, which can lead to kernel oops and panic of the form below on a<br /> Pseries-LPAR:<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x00000058<br /> <br /> NIP [c000000000506cb8] event_sched_out+0x40/0x258<br /> LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0<br /> Call Trace:<br /> [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (unreliable)<br /> [c00000025fc3fc80] [fffffffffffffee0] 0xfffffffffffffee0<br /> [c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120<br /> <br /> Kernel panic - not syncing: Aiee, killing interrupt handler!<br /> <br /> Fix this by adding the module ownership to &amp;#39;vpa_pmu&amp;#39; so that the module<br /> &amp;#39;vpa_pmu&amp;#39; is ref-counted and prevented from being unloaded when perf-events<br /> are initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix NULL dereference in SR-IOV VF creation error path<br /> <br /> Clean up when virtfn setup fails to prevent NULL pointer dereference<br /> during device removal. The kernel oops below occurred due to incorrect<br /> error handling flow when pci_setup_device() fails.<br /> <br /> Add pci_iov_scan_device(), which handles virtfn allocation and setup and<br /> cleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn&amp;#39;t need<br /> to call pci_stop_and_remove_bus_device(). This prevents accessing<br /> partially initialized virtfn devices during removal.<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000d0<br /> RIP: 0010:device_del+0x3d/0x3d0<br /> Call Trace:<br /> pci_remove_bus_device+0x7c/0x100<br /> pci_iov_add_virtfn+0xfa/0x200<br /> sriov_enable+0x208/0x420<br /> mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core]<br /> sriov_numvfs_store+0xae/0x1a0<br /> <br /> [bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix page_size variable overflow<br /> <br /> Change all variables storing mlx5_umem_mkc_find_best_pgsz() result to<br /> unsigned long to support values larger than 31 and avoid overflow.<br /> <br /> For example: If we try to register 4GB of memory that is contiguous in<br /> physical memory, the driver will optimize the page_size and try to use<br /> an mkey with 4GB entity size. The &amp;#39;unsigned int&amp;#39; page_size variable will<br /> overflow to &amp;#39;0&amp;#39; and we&amp;#39;ll hit the WARN_ON() in alloc_cacheable_mr().<br /> <br /> WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> Modules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core]<br /> CPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41<br /> RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246<br /> RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001<br /> RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600<br /> RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240<br /> R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00<br /> FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn+0x81/0x130<br /> ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> ? report_bug+0xfc/0x1e0<br /> ? handle_bug+0x55/0x90<br /> ? exc_invalid_op+0x17/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib]<br /> create_real_mr+0x54/0x150 [mlx5_ib]<br /> ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs]<br /> ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs]<br /> ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs]<br /> ? walk_system_ram_range+0x79/0xd0<br /> ? ___pte_offset_map+0x1b/0x110<br /> ? __pte_offset_map_lock+0x80/0x100<br /> ib_uverbs_ioctl+0xac/0x110 [ib_uverbs]<br /> __x64_sys_ioctl+0x94/0xb0<br /> do_syscall_64+0x50/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fb7ecf0737b<br /> Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b<br /> RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003<br /> RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4<br /> R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4<br /> R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150<br />