Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xprtrdma: Decrement re_receiving on the early exit paths<br /> <br /> In the event that rpcrdma_post_recvs() fails to create a work request<br /> (due to memory allocation failure, say) or otherwise exits early, we<br /> should decrement ep-&gt;re_receiving before returning. Otherwise we will<br /> hang in rpcrdma_xprt_drain() as re_receiving will never reach zero and<br /> the completion will never be triggered.<br /> <br /> On a system with high memory pressure, this can appear as the following<br /> hung task:<br /> <br /> INFO: task kworker/u385:17:8393 blocked for more than 122 seconds.<br /> Tainted: G S E 6.19.0 #3<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 task_flags:0x4248060 flags:0x00080000<br /> Workqueue: xprtiod xprt_autoclose [sunrpc]<br /> Call Trace:<br /> <br /> __schedule+0x48b/0x18b0<br /> ? ib_post_send_mad+0x247/0xae0 [ib_core]<br /> schedule+0x27/0xf0<br /> schedule_timeout+0x104/0x110<br /> __wait_for_common+0x98/0x180<br /> ? __pfx_schedule_timeout+0x10/0x10<br /> wait_for_completion+0x24/0x40<br /> rpcrdma_xprt_disconnect+0x444/0x460 [rpcrdma]<br /> xprt_rdma_close+0x12/0x40 [rpcrdma]<br /> xprt_autoclose+0x5f/0x120 [sunrpc]<br /> process_one_work+0x191/0x3e0<br /> worker_thread+0x2e3/0x420<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x10d/0x230<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x273/0x2b0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: fix stack out-of-bounds read in pipapo_drop()<br /> <br /> pipapo_drop() passes rulemap[i + 1].n to pipapo_unmap() as the<br /> to_offset argument on every iteration, including the last one where<br /> i == m-&gt;field_count - 1. This reads one element past the end of the<br /> stack-allocated rulemap array (declared as rulemap[NFT_PIPAPO_MAX_FIELDS]<br /> with NFT_PIPAPO_MAX_FIELDS == 16).<br /> <br /> Although pipapo_unmap() returns early when is_last is true without<br /> using the to_offset value, the argument is evaluated at the call site<br /> before the function body executes, making this a genuine out-of-bounds<br /> stack read confirmed by KASAN:<br /> <br /> BUG: KASAN: stack-out-of-bounds in pipapo_drop+0x50c/0x57c [nf_tables]<br /> Read of size 4 at addr ffff8000810e71a4<br /> <br /> This frame has 1 object:<br /> [32, 160) &amp;#39;rulemap&amp;#39;<br /> <br /> The buggy address is at offset 164 -- exactly 4 bytes past the end<br /> of the rulemap array.<br /> <br /> Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid<br /> the out-of-bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix for duplicate device in netdev hooks<br /> <br /> When handling NETDEV_REGISTER notification, duplicate device<br /> registration must be avoided since the device may have been added by<br /> nft_netdev_hook_alloc() already when creating the hook.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: route: hold key-&gt;lock in mctp_flow_prepare_output()<br /> <br /> mctp_flow_prepare_output() checks key-&gt;dev and may call<br /> mctp_dev_set_key(), but it does not hold key-&gt;lock while doing so.<br /> <br /> mctp_dev_set_key() and mctp_dev_release_key() are annotated with<br /> __must_hold(&amp;key-&gt;lock), so key-&gt;dev access is intended to be<br /> serialized by key-&gt;lock. The mctp_sendmsg() transmit path reaches<br /> mctp_flow_prepare_output() via mctp_local_output() -&gt; mctp_dst_output()<br /> without holding key-&gt;lock, so the check-and-set sequence is racy.<br /> <br /> Example interleaving:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> mctp_flow_prepare_output(key, devA)<br /> if (!key-&gt;dev) // sees NULL<br /> mctp_flow_prepare_output(<br /> key, devB)<br /> if (!key-&gt;dev) // still NULL<br /> mctp_dev_set_key(devB, key)<br /> mctp_dev_hold(devB)<br /> key-&gt;dev = devB<br /> mctp_dev_set_key(devA, key)<br /> mctp_dev_hold(devA)<br /> key-&gt;dev = devA // overwrites devB<br /> <br /> Now both devA and devB references were acquired, but only the final<br /> key-&gt;dev value is tracked for release. One reference can be lost,<br /> causing a resource leak as mctp_dev_release_key() would only decrease<br /> the reference on one dev.<br /> <br /> Fix by taking key-&gt;lock around the key-&gt;dev check and<br /> mctp_dev_set_key() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix type confusion in bond_setup_by_slave()<br /> <br /> kernel BUG at net/core/skbuff.c:2306!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306<br /> RSP: 0018:ffffc90004aff760 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e<br /> RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900<br /> RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780<br /> R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900<br /> dev_hard_header include/linux/netdevice.h:3439 [inline]<br /> packet_snd net/packet/af_packet.c:3028 [inline]<br /> packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592<br /> ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646<br /> __sys_sendmsg+0x170/0x220 net/socket.c:2678<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe1a0e6c1a9<br /> <br /> When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,<br /> bond_setup_by_slave() directly copies the slave&amp;#39;s header_ops to the<br /> bond device:<br /> <br /> bond_dev-&gt;header_ops = slave_dev-&gt;header_ops;<br /> <br /> This causes a type confusion when dev_hard_header() is later called<br /> on the bond device. Functions like ipgre_header(), ip6gre_header(),all use<br /> netdev_priv(dev) to access their device-specific private data. When<br /> called with the bond device, netdev_priv() returns the bond&amp;#39;s private<br /> data (struct bonding) instead of the expected type (e.g. struct<br /> ip_tunnel), leading to garbage values being read and kernel crashes.<br /> <br /> Fix this by introducing bond_header_ops with wrapper functions that<br /> delegate to the active slave&amp;#39;s header_ops using the slave&amp;#39;s own<br /> device. This ensures netdev_priv() in the slave&amp;#39;s header functions<br /> always receives the correct device.<br /> <br /> The fix is placed in the bonding driver rather than individual device<br /> drivers, as the root cause is bond blindly inheriting header_ops from<br /> the slave without considering that these callbacks expect a specific<br /> netdev_priv() layout.<br /> <br /> The type confusion can be observed by adding a printk in<br /> ipgre_header() and running the following commands:<br /> <br /> ip link add dummy0 type dummy<br /> ip addr add 10.0.0.1/24 dev dummy0<br /> ip link set dummy0 up<br /> ip link add gre1 type gre local 10.0.0.1<br /> ip link add bond1 type bond mode active-backup<br /> ip link set gre1 master bond1<br /> ip link set gre1 up<br /> ip link set bond1 up<br /> ip addr add fe80::1/64 dev bond1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: i2c: fix skb memory leak in receive path<br /> <br /> When &amp;#39;midev-&gt;allow_rx&amp;#39; is false, the newly allocated skb isn&amp;#39;t consumed<br /> by netif_rx(), it needs to free the skb directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: caif: hold tty-&gt;link reference in ldisc_open and ser_release<br /> <br /> A reproducer triggers a KASAN slab-use-after-free in pty_write_room()<br /> when caif_serial&amp;#39;s TX path calls tty_write_room(). The faulting access<br /> is on tty-&gt;link-&gt;port.<br /> <br /> Hold an extra kref on tty-&gt;link for the lifetime of the caif_serial line<br /> discipline: get it in ldisc_open() and drop it in ser_release(), and<br /> also drop it on the ldisc_open() error path.<br /> <br /> With this change applied, the reproducer no longer triggers the UAF in<br /> my testing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-core: flush delayed work before removing DAIs and widgets<br /> <br /> When a sound card is unbound while a PCM stream is open, a<br /> use-after-free can occur in snd_soc_dapm_stream_event(), called from<br /> the close_delayed_work workqueue handler.<br /> <br /> During unbind, snd_soc_unbind_card() flushes delayed work and then<br /> calls soc_cleanup_card_resources(). Inside cleanup,<br /> snd_card_disconnect_sync() releases all PCM file descriptors, and<br /> the resulting PCM close path can call snd_soc_dapm_stream_stop()<br /> which schedules new delayed work with a pmdown_time timer delay.<br /> Since this happens after the flush in snd_soc_unbind_card(), the<br /> new work is not caught. soc_remove_link_components() then frees<br /> DAPM widgets before this work fires, leading to the use-after-free.<br /> <br /> The existing flush in soc_free_pcm_runtime() also cannot help as it<br /> runs after soc_remove_link_components() has already freed the widgets.<br /> <br /> Add a flush in soc_cleanup_card_resources() after<br /> snd_card_disconnect_sync() (after which no new PCM closes can<br /> schedule further delayed work) and before soc_remove_link_dais()<br /> and soc_remove_link_components() (which tear down the structures the<br /> delayed work accesses).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: rockchip-sfc: Fix double-free in remove() callback<br /> <br /> The driver uses devm_spi_register_controller() for registration, which<br /> automatically unregisters the controller via devm cleanup when the<br /> device is removed. The manual call to spi_unregister_controller() in<br /> the remove() callback can lead to a double-free.<br /> <br /> And to make sure controller is unregistered before DMA buffer is<br /> unmapped, switch to use spi_register_controller() in probe().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic: spifc-a4: Fix DMA mapping error handling<br /> <br /> Fix three bugs in aml_sfc_dma_buffer_setup() error paths:<br /> 1. Unnecessary goto: When the first DMA mapping (sfc-&gt;daddr) fails,<br /> nothing needs cleanup. Use direct return instead of goto.<br /> 2. Double-unmap bug: When info DMA mapping failed, the code would<br /> unmap sfc-&gt;daddr inline, then fall through to out_map_data which<br /> would unmap it again, causing a double-unmap.<br /> 3. Wrong unmap size: The out_map_info label used datalen instead of<br /> infolen when unmapping sfc-&gt;iaddr, which could lead to incorrect<br /> DMA sync behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix runtime suspend deadlock when there is pending job<br /> <br /> The runtime suspend callback drains the running job workqueue before<br /> suspending the device. If a job is still executing and calls<br /> pm_runtime_resume_and_get(), it can deadlock with the runtime suspend<br /> path.<br /> <br /> Fix this by moving pm_runtime_resume_and_get() from the job execution<br /> routine to the job submission routine, ensuring the device is resumed<br /> before the job is queued and avoiding the deadlock during runtime<br /> suspend.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: fix PTP use-after-free during reset<br /> <br /> Commit 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") introduced a<br /> worker to cache PHC time, but failed to stop it during reset or disable.<br /> <br /> This creates a race condition where `iavf_reset_task()` or<br /> `iavf_disable_vf()` free adapter resources (AQ) while the worker is still<br /> running. If the worker triggers `iavf_queue_ptp_cmd()` during teardown, it<br /> accesses freed memory/locks, leading to a crash.<br /> <br /> Fix this by calling `iavf_ptp_release()` before tearing down the adapter.<br /> This ensures `ptp_clock_unregister()` synchronously cancels the worker and<br /> cleans up the chardev before the backing resources are destroyed.