Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/io-pgtable-arm: fix size_t signedness bug in unmap path<br /> <br /> __arm_lpae_unmap() returns size_t but was returning -ENOENT (negative<br /> error code) when encountering an unmapped PTE. Since size_t is unsigned,<br /> -ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE<br /> on 64-bit systems).<br /> <br /> This corrupted value propagates through the call chain:<br /> __arm_lpae_unmap() returns -ENOENT as size_t<br /> -&gt; arm_lpae_unmap_pages() returns it<br /> -&gt; __iommu_unmap() adds it to iova address<br /> -&gt; iommu_pgsize() triggers BUG_ON due to corrupted iova<br /> <br /> This can cause IOVA address overflow in __iommu_unmap() loop and<br /> trigger BUG_ON in iommu_pgsize() from invalid address alignment.<br /> <br /> Fix by returning 0 instead of -ENOENT. The WARN_ON already signals<br /> the error condition, and returning 0 (meaning "nothing unmapped")<br /> is the correct semantic for size_t return type. This matches the<br /> behavior of other io-pgtable implementations (io-pgtable-arm-v7s,<br /> io-pgtable-dart) which return 0 on error conditions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Octeontx2-af: Add proper checks for fwdata<br /> <br /> firmware populates MAC address, link modes (supported, advertised)<br /> and EEPROM data in shared firmware structure which kernel access<br /> via MAC block(CGX/RPM).<br /> <br /> Accessing fwdata, on boards booted with out MAC block leading to<br /> kernel panics.<br /> <br /> Internal error: Oops: 0000000096000005 [#1] SMP<br /> [ 10.460721] Modules linked in:<br /> [ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT<br /> [ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)<br /> [ 10.479793] Workqueue: events work_for_cpu_fn<br /> [ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 10.491124] pc : rvu_sdp_init+0x18/0x114<br /> [ 10.495051] lr : rvu_probe+0xe58/0x1d18

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/sched: act_ife: avoid possible NULL deref<br /> <br /> tcf_ife_encode() must make sure ife_encode() does not return NULL.<br /> <br /> syzbot reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166<br /> CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full)<br /> Call Trace:<br /> <br /> ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101<br /> tcf_ife_encode net/sched/act_ife.c:841 [inline]<br /> tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877<br /> tc_act include/net/tc_wrapper.h:130 [inline]<br /> tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152<br /> tcf_exts_exec include/net/pkt_cls.h:349 [inline]<br /> mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42<br /> tc_classify include/net/tc_wrapper.h:197 [inline]<br /> __tcf_classify net/sched/cls_api.c:1764 [inline]<br /> tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860<br /> multiq_classify net/sched/sch_multiq.c:39 [inline]<br /> multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66<br /> dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147<br /> __dev_xmit_skb net/core/dev.c:4262 [inline]<br /> __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-sprd-adi: Fix double free in probe error path<br /> <br /> The driver currently uses spi_alloc_host() to allocate the controller<br /> but registers it using devm_spi_register_controller().<br /> <br /> If devm_register_restart_handler() fails, the code jumps to the<br /> put_ctlr label and calls spi_controller_put(). However, since the<br /> controller was registered via a devm function, the device core will<br /> automatically call spi_controller_put() again when the probe fails.<br /> This results in a double-free of the spi_controller structure.<br /> <br /> Fix this by switching to devm_spi_alloc_host() and removing the<br /> manual spi_controller_put() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix potential underflow in virtio_transport_get_credit()<br /> <br /> The credit calculation in virtio_transport_get_credit() uses unsigned<br /> arithmetic:<br /> <br /> ret = vvs-&gt;peer_buf_alloc - (vvs-&gt;tx_cnt - vvs-&gt;peer_fwd_cnt);<br /> <br /> If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes<br /> are in flight, the subtraction can underflow and produce a large<br /> positive value, potentially allowing more data to be queued than the<br /> peer can handle.<br /> <br /> Reuse virtio_transport_has_space() which already handles this case and<br /> add a comment to make it clear why we are doing that.<br /> <br /> [Stefano: use virtio_transport_has_space() instead of duplicating the code]<br /> [Stefano: tweak the commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: Fix race condition in hwspinlock irqsave routine<br /> <br /> Previously, the address of the shared member &amp;#39;&amp;map-&gt;spinlock_flags&amp;#39; was<br /> passed directly to &amp;#39;hwspin_lock_timeout_irqsave&amp;#39;. This creates a race<br /> condition where multiple contexts contending for the lock could overwrite<br /> the shared flags variable, potentially corrupting the state for the<br /> current lock owner.<br /> <br /> Fix this by using a local stack variable &amp;#39;flags&amp;#39; to store the IRQ state<br /> temporarily.

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 /> 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 /> 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 /> 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 /> 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.