Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: Fix memleak in l2tp_udp_encap_recv().<br /> <br /> syzbot reported memleak of struct l2tp_session, l2tp_tunnel,<br /> sock, etc. [0]<br /> <br /> The cited commit moved down the validation of the protocol<br /> version in l2tp_udp_encap_recv().<br /> <br /> The new place requires an extra error handling to avoid the<br /> memleak.<br /> <br /> Let&amp;#39;s call l2tp_session_put() there.<br /> <br /> [0]:<br /> BUG: memory leak<br /> unreferenced object 0xffff88810a290200 (size 512):<br /> comm "syz.0.17", pid 6086, jiffies 4294944299<br /> hex dump (first 32 bytes):<br /> 7d eb 04 0c 00 00 00 00 01 00 00 00 00 00 00 00 }...............<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc babb6a4f):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> __do_kmalloc_node mm/slub.c:5656 [inline]<br /> __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c:1778<br /> pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755<br /> __sys_connect_file+0x7a/0xb0 net/socket.c:2089<br /> __sys_connect+0xde/0x110 net/socket.c:2108<br /> __do_sys_connect net/socket.c:2114 [inline]<br /> __se_sys_connect net/socket.c:2111 [inline]<br /> __x64_sys_connect+0x1c/0x30 net/socket.c:2111<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hv_netvsc: reject RSS hash key programming without RX indirection table<br /> <br /> RSS configuration requires a valid RX indirection table. When the device<br /> reports a single receive queue, rndis_filter_device_add() does not<br /> allocate an indirection table, accepting RSS hash key updates in this<br /> state leads to a hang.<br /> <br /> Fix this by gating netvsc_set_rxfh() on ndc-&gt;rx_table_sz and return<br /> -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device<br /> capabilities and prevents incorrect behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: riic: Move suspend handling to NOIRQ phase<br /> <br /> Commit 53326135d0e0 ("i2c: riic: Add suspend/resume support") added<br /> suspend support for the Renesas I2C driver and following this change<br /> on RZ/G3E the following WARNING is seen on entering suspend ...<br /> <br /> [ 134.275704] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)<br /> [ 134.285536] ------------[ cut here ]------------<br /> [ 134.290298] i2c i2c-2: Transfer while suspended<br /> [ 134.295174] WARNING: drivers/i2c/i2c-core.h:56 at __i2c_smbus_xfer+0x1e4/0x214, CPU#0: systemd-sleep/388<br /> [ 134.365507] Tainted: [W]=WARN<br /> [ 134.368485] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT)<br /> [ 134.375961] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 134.382935] pc : __i2c_smbus_xfer+0x1e4/0x214<br /> [ 134.387329] lr : __i2c_smbus_xfer+0x1e4/0x214<br /> [ 134.391717] sp : ffff800083f23860<br /> [ 134.395040] x29: ffff800083f23860 x28: 0000000000000000 x27: ffff800082ed5d60<br /> [ 134.402226] x26: 0000001f4395fd74 x25: 0000000000000007 x24: 0000000000000001<br /> [ 134.409408] x23: 0000000000000000 x22: 000000000000006f x21: ffff800083f23936<br /> [ 134.416589] x20: ffff0000c090e140 x19: ffff0000c090e0d0 x18: 0000000000000006<br /> [ 134.423771] x17: 6f63657320313030 x16: 2e30206465737061 x15: ffff800083f23280<br /> [ 134.430953] x14: 0000000000000000 x13: ffff800082b16ce8 x12: 0000000000000f09<br /> [ 134.438134] x11: 0000000000000503 x10: ffff800082b6ece8 x9 : ffff800082b16ce8<br /> [ 134.445315] x8 : 00000000ffffefff x7 : ffff800082b6ece8 x6 : 80000000fffff000<br /> [ 134.452495] x5 : 0000000000000504 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 134.459672] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c9ee9e80<br /> [ 134.466851] Call trace:<br /> [ 134.469311] __i2c_smbus_xfer+0x1e4/0x214 (P)<br /> [ 134.473715] i2c_smbus_xfer+0xbc/0x120<br /> [ 134.477507] i2c_smbus_read_byte_data+0x4c/0x84<br /> [ 134.482077] isl1208_i2c_read_time+0x44/0x178 [rtc_isl1208]<br /> [ 134.487703] isl1208_rtc_read_time+0x14/0x20 [rtc_isl1208]<br /> [ 134.493226] __rtc_read_time+0x44/0x88<br /> [ 134.497012] rtc_read_time+0x3c/0x68<br /> [ 134.500622] rtc_suspend+0x9c/0x170<br /> <br /> The warning is triggered because I2C transfers can still be attempted<br /> while the controller is already suspended, due to inappropriate ordering<br /> of the system sleep callbacks.<br /> <br /> If the controller is autosuspended, there is no way to wake it up once<br /> runtime PM disabled (in suspend_late()). During system resume, the I2C<br /> controller will be available only after runtime PM is re-enabled<br /> (in resume_early()). However, this may be too late for some devices.<br /> <br /> Wake up the controller in the suspend() callback while runtime PM is<br /> still enabled. The I2C controller will remain available until the<br /> suspend_noirq() callback (pm_runtime_force_suspend()) is called. During<br /> resume, the I2C controller can be restored by the resume_noirq() callback<br /> (pm_runtime_force_resume()). Finally, the resume() callback re-enables<br /> autosuspend. As a result, the I2C controller can remain available until<br /> the system enters suspend_noirq() and from resume_noirq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: implement mremap in uacce_vm_ops to return -EPERM<br /> <br /> The current uacce_vm_ops does not support the mremap operation of<br /> vm_operations_struct. Implement .mremap to return -EPERM to remind<br /> users.<br /> <br /> The reason we need to explicitly disable mremap is that when the<br /> driver does not implement .mremap, it uses the default mremap<br /> method. This could lead to a risk scenario:<br /> <br /> An application might first mmap address p1, then mremap to p2,<br /> followed by munmap(p1), and finally munmap(p2). Since the default<br /> mremap copies the original vma&amp;#39;s vm_private_data (i.e., q) to the<br /> new vma, both munmap operations would trigger vma_close, causing<br /> q-&gt;qfr to be freed twice(qfr will be set to null here, so repeated<br /> release is ok).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: Coalesce only linear skb<br /> <br /> vsock/virtio common tries to coalesce buffers in rx queue: if a linear skb<br /> (with a spare tail room) is followed by a small skb (length limited by<br /> GOOD_COPY_LEN = 128), an attempt is made to join them.<br /> <br /> Since the introduction of MSG_ZEROCOPY support, assumption that a small skb<br /> will always be linear is incorrect. In the zerocopy case, data is lost and<br /> the linear skb is appended with uninitialized kernel memory.<br /> <br /> Of all 3 supported virtio-based transports, only loopback-transport is<br /> affected. G2H virtio-transport rx queue operates on explicitly linear skbs;<br /> see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2G<br /> vhost-transport may allocate non-linear skbs, but only for sizes that are<br /> not considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER in<br /> virtio_vsock_alloc_skb().<br /> <br /> Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) &gt; 0<br /> guarantees last_skb is linear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In ems_usb_open(), the URBs for USB-in transfers are allocated, added to<br /> the dev-&gt;rx_submitted anchor and submitted. In the complete callback<br /> ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In<br /> ems_usb_close() the URBs are freed by calling<br /> usb_kill_anchored_urbs(&amp;dev-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in ems_usb_close().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> ems_usb_read_bulk_callback() to the dev-&gt;rx_submitted anchor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Sanitize payload size to prevent member overflow<br /> <br /> In qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_size<br /> reported by firmware is used to calculate the copy length into<br /> item-&gt;iocb. However, the iocb member is defined as a fixed-size 64-byte<br /> array within struct purex_item.<br /> <br /> If the reported frame_size exceeds 64 bytes, subsequent memcpy calls will<br /> overflow the iocb member boundary. While extra memory might be allocated,<br /> this cross-member write is unsafe and triggers warnings under<br /> CONFIG_FORTIFY_SOURCE.<br /> <br /> Fix this by capping total_bytes to the size of the iocb member (64 bytes)<br /> before allocation and copying. This ensures all copies remain within the<br /> bounds of the destination structure member.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: authencesn - reject too-short AAD (assoclen

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak<br /> <br /> Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb:<br /> gs_usb_receive_bulk_callback(): fix URB memory leak").<br /> <br /> In kvaser_usb_set_{,data_}bittiming() -&gt; kvaser_usb_setup_rx_urbs(), the<br /> URBs for USB-in transfers are allocated, added to the dev-&gt;rx_submitted<br /> anchor and submitted. In the complete callback<br /> kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In<br /> kvaser_usb_remove_interfaces() the URBs are freed by calling<br /> usb_kill_anchored_urbs(&amp;dev-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in usb_kill_anchored_urbs().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> kvaser_usb_read_bulk_callback() to the dev-&gt;rx_submitted anchor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro<br /> <br /> The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs<br /> attributes:<br /> <br /> 1. Off-by-one error: The loop condition used &amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uacce: ensure safe queue release with state management<br /> <br /> Directly calling `put_queue` carries risks since it cannot<br /> guarantee that resources of `uacce_queue` have been fully released<br /> beforehand. So adding a `stop_queue` operation for the<br /> UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to<br /> the final resource release ensures safety.<br /> <br /> Queue states are defined as follows:<br /> - UACCE_Q_ZOMBIE: Initial state<br /> - UACCE_Q_INIT: After opening `uacce`<br /> - UACCE_Q_STARTED: After `start` is issued via `ioctl`<br /> <br /> When executing `poweroff -f` in virt while accelerator are still<br /> working, `uacce_fops_release` and `uacce_remove` may execute<br /> concurrently. This can cause `uacce_put_queue` within<br /> `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add<br /> state checks to prevent accessing freed pointers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel<br /> <br /> The connector type for the DataImage SCF0700C48GGU18 panel is missing and<br /> devm_drm_panel_bridge_add() requires connector type to be set. This leads<br /> to a warning and a backtrace in the kernel log and panel does not work:<br /> "<br /> WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8<br /> "<br /> The warning is triggered by a check for valid connector type in<br /> devm_drm_panel_bridge_add(). If there is no valid connector type<br /> set for a panel, the warning is printed and panel is not added.<br /> Fill in the missing connector type to fix the warning and make<br /> the panel operational once again.