Repository navigation
Merge tag 'v6.18.52' into qcom-6.18.y - #1158
nsiddams (nsiddams) wants to merge 3233 commits into
Conversation
[ Upstream commit 7b196e2 ] mv88e6352_pcs_link_check() ignores errors returned by port_get_cmode(). If the port status register read fails, mv88e6352_port_get_cmode() returns without setting cmode. The link check then compares an uninitialized value and may incorrectly treat the PCS as active. Save the return value and fail the link check after releasing the register lock. marvell_c22_pcs_get_state() initializes the reported link state to down before calling the check, so a read failure is handled safely until a later poll succeeds. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 8576455 ("net: dsa: mv88e6xxx: convert 88e6352 to phylink_pcs") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20260813153131.3952970-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9466ef3 ] The TCP receive queue can hold adjacent skbs whose sequence ranges overlap. The tls fast-path reads the record header with skb_copy_bits() by byte offset, which assumes skbs do not overlap, so a header split across the overlap is misread and the connection aborts (-EMSGSIZE/-EINVAL). tls_strp_check_queue_ok() detects such overlaps but only ran after the header was parsed, never covering the header itself. Observed with parallel kTLS connections on: - ConnectX-7 + IPsec crypto offload + GRO - VirtIO (8 queues) + GRO Fixes: 84c61fe ("tls: rx: do not use the standard strparser") Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com> Link: https://patch.msgid.link/20260813121337.3300688-1-maxbr@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 21040c7 ] A notification should be emitted only when the vlan delete was successful and not otherwise. The proper check is if br/nbp_vlan_delete returned 0. Fixes: f545923 ("net: bridge: vlan: notify on vlan add/delete/change flags") Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260814141640.64958-1-razor@blackwall.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4deb3ed ] Since commit 053fc4f ("fuse: fix UAF in rcu pathwalks"), fuse_conn_put() frees the fuse_conn through call_rcu() rather than synchronously. For cuse, fc->release is cuse_fc_release(), which lives in the cuse module. If the module is removed before the RCU grace period ends, the callback jumps into freed module memory: userspace / module unload | RCU softirq ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ close(/dev/cuse) | cuse_channel_release() | fuse_dev_release() | fuse_conn_put(fch->conn) | call_rcu(delayed_release) ------+---> callback queued | rmmod cuse | cuse_exit() | cuse_channel_destroy() | ... | return | | <module text freed> | | rcu_do_batch() | delayed_release() | fc->release() | -> cuse_fc_release() | ^^^ freed text! The freed module text is unmapped by vfree(), so the jump into the stale callback triggers a page-fault Oops. If the virtual address is subsequently reused, the callback could execute unrelated code (undefined behaviour). Fix this by calling rcu_barrier() in cuse_exit() so that any pending fuse_conn release callback completes before the module is removed. Fixes: 053fc4f ("fuse: fix UAF in rcu pathwalks") Signed-off-by: Baokun Li <libaokun@linux.alibaba.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit de603b9 ] read_log_rec_buf() copies a log record into a caller buffer starting at u32 off = lsn_to_page_off(log, lsn) + log->record_header_len; log->record_header_len (and log->data_off, used for the following pages) comes verbatim from the on-disk restart area and is only checked for 8-byte alignment in is_rst_area_valid(), so off can exceed log->page_size. "tail = log->page_size - off" then underflows and memcpy() reads past the page_size-sized buffer returned by read_log_page(), spilling adjacent slab memory into the replay buffer. This is reachable by mounting a crafted NTFS image: BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580 Read of size 64 at addr ffff88800a877ff8 by task exploit/127 read_log_rec_buf fs/ntfs3/fslog.c:2299 log_replay fs/ntfs3/fslog.c:4216 ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324 ntfs_fill_super fs/ntfs3/super.c:1392 get_tree_bdev_flags fs/super.c:1694 __x64_sys_mount fs/namespace.c:4360 The buggy address is located 4088 bytes to the right of the 4096-byte region [ffff88800a876000, ffff88800a877000) Reject an in-page offset outside the current page before the copy. Fixes: b46acd6 ("fs/ntfs3: Add NTFS journal") Assisted-by: Claude:claude-opus-4-8 Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> [almaz.alexandrovich@paragon-software.com: replaced the >= sign with >] Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c22f91d ] When an EA record has a non-zero ef->size, ntfs_read_ea() only checks that the record fits in the remaining buffer (ea_size > bytes), not that ef->size is large enough to hold the record's own name_len + 1 + elength. A crafted image can pass validation with, e.g., ef->size = 24 but elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of the undersized record, reading past the kmalloc(info->size) allocation and leaking heap memory to userspace via getxattr(): BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302) Read of size 65535 at addr ffff888100794550 by task exploit __asan_memcpy (mm/kasan/shadow.c:105) ntfs_get_ea (fs/ntfs3/xattr.c:302) ntfs_getxattr (fs/ntfs3/xattr.c:848) __vfs_getxattr (fs/xattr.c:441) vfs_getxattr (fs/xattr.c:474) do_getxattr (fs/xattr.c:800) path_getxattrat (fs/xattr.c:868) do_syscall_64 (arch/x86/entry/syscall_64.c:94) The buggy address is located 80 bytes inside of allocated 84-byte region in cache kmalloc-96 Compute the size the record needs and require ef->size to cover it. Fixes: 0e8235d ("fs/ntfs3: Check fields while reading") Reported-by: Xiang Mei <xmei5@asu.edu> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c6441be ] When CONFIG_QCOM_UBWC_CONFIG=n, compiler needs to know the definition of ERR_PTR otherwise there will be a compilation error: In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.c:7: ./include/linux/soc/qcom/ubwc.h: In function ‘qcom_ubwc_config_get_data’: ./include/linux/soc/qcom/ubwc.h:45:16: error: implicit declaration of function ‘ERR_PTR’ [-Wimplicit-function-declaration] Fix this by including <linux/err.h> Fixes: 1924272 ("soc: qcom: Add UBWC config provider") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 928f659 ] fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it: root = fuse_iget(sb, parent_fi->nodeid, ...); fi = get_fuse_inode(root); fi->nlookup--; Inside fuse_iget() the inode allocation can fail and return NULL. The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()): inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid); if (!inode) return NULL; A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount. With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure): ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 qualcomm-linux#15 Call Trace: <TASK> fuse_get_tree_submount+0x656/0x8b0 vfs_get_tree+0x48/0x140 fc_mount+0x13/0x50 fuse_dentry_automount+0x7a/0xb0 __traverse_mounts+0xca/0x330 step_into+0x339/0xac0 path_lookupat+0xc5/0x2f0 filename_lookup+0x163/0x2a0 vfs_statx+0xd5/0x200 do_statx+0x83/0xd0 __x64_sys_statx+0xa0/0xc0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x78/0xe2 </TASK> ================================================================== Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function. Fixes: 1866d77 ("fuse: Allow fuse_fill_super_common() for submounts") Signed-off-by: Baokun Li <libaokun@linux.alibaba.com> Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c139e7e ] print_conn_list() compares the raw hardware connection list with the connection list cached by the HDA driver. When they differ, it prints an additional "In-driver Connection" line so that /proc/asound/card*/codec#* shows the topology actually used by the driver. The comparison currently passes conn_len directly to memcmp(). However, conn_len is a number of connection-list entries, while memcmp() expects a size in bytes. Both list and conn are arrays of hda_nid_t, which is u16, so only half of the connection data is compared. For example, for two-entry lists such as: hardware: 0x0c 0x0d cached: 0x0c 0x0e conn_len is 2, and the current comparison checks only the first hda_nid_t. The lists are therefore incorrectly treated as identical even though the second connection differs. This can happen legitimately when codec fixups replace a cached connection list with snd_hda_override_conn_list(). The codec routing used by the driver is not affected, but the proc output can hide the overridden driver-visible routing and provide misleading topology information during codec debugging. Convert the entry count to a byte size so that memcmp() covers the complete connection list. Fixes: 8b2c7a5 ("ALSA: hda - Add In-driver connection info") Signed-off-by: Xu Rao <raoxu@uniontech.com> Link: https://patch.msgid.link/7B802A4E225CC808+20260818083808.2735120-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bc2dc66 ] vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry. Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes: vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put() Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processed. The next iteration calls hlist_del() on it again, writing LIST_POISON1 to LIST_POISON2 [1]. Besides device deletion, the flush is also reachable from RTM_DELMDB with NLM_F_BULK. Fix by re-reading the next entry after the remotes were flushed. The current entry cannot be removed by this flush, as source lists can only be configured on (*, G) entries and the removed entries are (S, G) entries. It is therefore still linked and its next pointer reflects the removals. [1] BUG: KASAN: wild-memory-access in vxlan_mdb_entry_put.part.0+0x328/0x588 Write of size 8 at addr dead000000000122 by task ip/327 CPU: 3 UID: 1000 PID: 327 Comm: ip Not tainted 7.2.0-rc7 qualcomm-linux#2 PREEMPT Call trace: vxlan_mdb_entry_put.part.0+0x328/0x588 vxlan_mdb_flush+0x1d8/0x25c vxlan_mdb_fini+0x8c/0x100 vxlan_uninit+0x1c/0x7c unregister_netdevice_many_notify+0x954/0xd4c rtnl_dellink+0x210/0x530 rtnetlink_rcv_msg+0x434/0x4d0 netlink_rcv_skb+0xc4/0x204 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x548 netlink_sendmsg+0x29c/0x560 ____sys_sendmsg+0x390/0x3ec ___sys_sendmsg+0x114/0x188 __sys_sendmsg+0xf0/0x178 __arm64_sys_sendmsg+0x48/0x60 invoke_syscall.constprop.0+0x58/0x180 el0_svc_common.constprop.0+0x74/0x140 do_el0_svc+0x30/0x40 el0_svc+0x38/0x98 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Fixes: a3a48de ("vxlan: mdb: Add MDB control path support") Signed-off-by: Baul Lee <baul.lee@xbow.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260814153547.29567-1-baul.lee@xbow.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cb7643b ] On QEMU rtl8139 model, frames that arrive while the interface is suspended still end up in the stack after resume. With pm_test=devices, which keeps devices suspended for 5s, 200 frames sent to interface during that time and 50 frames after resume, eth0 reports 113 received frames. cp_suspend() is supposed to stop receiver and the transmitter, but the mask is wrong: (~RxOn | ~TxOn) is ~0, nothing is cleared and Cmd still reads 0x0d when cp_suspend() returns. Use ~(RxOn | TxOn) so both bits are actually cleared. Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260817043057.20099-1-kmehltretter@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8acf691 ] smc_sk_init() calls sk->sk_prot->hash(sk) before several fields are fully initialised: clcsock_release_lock, the saved clcsk_* callbacks, use_fallback/fallback_rsn, and conn.close_work. Once hash() returns the socket is visible to concurrent hash walkers, which can then observe uninitialised state. Move hash(sk) to the end of smc_sk_init() so the socket is published only after it is fully constructed. Fixes: d0e3565 ("net/smc: refactoring initialization of smc sock") Reviewed-by: Hidayath Khan <hidayath@linux.ibm.com> Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com> Link: https://patch.msgid.link/20260813074315.554926-1-mjambigi@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5ab078e ] The get_instance_id() macro walks the per-type attribute array with 'i <= instances_count'. Each array is allocated with exactly instances_count entries, so the valid range is [0, instances_count) and the last iteration reads one element past the end. On a name miss that out-of-bounds attribute_name is handed to strcmp(), which reads on until it finds a NUL byte. Every kobject in these ksets is built from an entry that was populated, so a miss does not look reachable from sysfs today. The bound is wrong either way and the read is out of bounds. The matching macro in hp-bioscfg carried the same off-by-one and was corrected by commit 2515071 ("platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro"). That macro takes a kobject pointer out of the out-of-bounds element and dereferences it, so it could fault. This one reads a char array. Use '<' to match the allocation. Fixes: e8a60aa ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 98f28d8 ] A common pattern in epoll network servers is to eagerly accept all pending connections from the non-blocking listening socket after epoll_wait indicates the socket is ready by calling accept in a loop until EAGAIN is returned indicating that the backlog is empty. Scheduling a timeout for a non-blocking accept with an empty backlog meant AF_VSOCK sockets used by epoll network servers incurred hundreds of microseconds of additional latency per accept loop compared to AF_INET or AF_UNIX sockets. Signed-off-by: Laurence Rowe <laurencerowe@gmail.com> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20260402204918.130395-1-laurencerowe@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Stable-dep-of: b8c899c ("vsock: don't check the listener's sk_err in vsock_accept()") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b8c899c ] Syzbot reported an issue which can be reproduced with these steps: r0 = socket(AF_VSOCK, SOCK_STREAM, 0) bind(r0, {VMADDR_CID_ANY, PORT}) connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) listen(r0, backlog) -> 0 r1 = socket(AF_VSOCK, SOCK_STREAM, 0) connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 accept(r0) -> -1, EPROTO (stale sk_err) Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO. After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect. This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket. For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously. Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above. Fixes: d021c34 ("VSOCK: Introduce VM Sockets") Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678 Suggested-by: Michal Luczaj <mhal@rbox.co> Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20260813173024.2362935-2-phind.uet@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 96cbf89 ] vsock_connect() returns sk_err to userspace but does not clear it: if (sk->sk_err) { err = -sk->sk_err; For a blocking connect() the error has already been delivered as connect()'s return value, so leaving it set causes subsequent operations like poll()/epoll() to keep reporting POLLERR even though the connect failure was already delivered. The error should be consumed once it has been returned to userspace. Switch to sock_error(), which reads and clears sk_err atomically, matching the behavior of other protocol implementations such as __inet_stream_connect(). Fixes: d021c34 ("VSOCK: Introduce VM Sockets") Tested-by: Wupeng Ma <mawupeng1@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com> Link: https://patch.msgid.link/20260813173024.2362935-4-phind.uet@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e213939 ] The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values]. Fixes: 8646a3b ("platform/x86: hp-bioscfg: passwdobj-attributes") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Link: https://patch.msgid.link/20260708090937.740435-1-lgs201920130244@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3921bb8 ] hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works Fixes: 92c025d ("platform/x86/amd/hsmp: Report power via hwmon sensors") Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Link: https://patch.msgid.link/20260812090012.140193-1-hemanth.selam@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 46b14c6 ] rsh_log_store() calls the FIELD_PREP() macro without including the required header file, resulting a build error: CC drivers/platform/mellanox/mlxbf-bootctl.o drivers/platform/mellanox/mlxbf-bootctl.c: In function ‘rsh_log_store’: drivers/platform/mellanox/mlxbf-bootctl.c:429:16: error: implicit declaration of function ‘FIELD_PREP’ [-Wimplicit-function-declaration] 429 | data = FIELD_PREP(MLXBF_RSH_LOG_TYPE_MASK, MLXBF_RSH_LOG_TYPE_MSG); | ^~~~~~~~~~ Fix this by including the <linux/bitfield.h> file. Fixes: e9d1b2d ("mlxbf-bootctl: Add sysfs file for BlueField boot log") Signed-off-by: Nikolay Kulikov <nikolayof23@gmail.com> Link: https://patch.msgid.link/20260810-mellanox_fix_implicit_declaration-v1-1-352e647b8f28@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8ccc9bf ] Empty NLA_NESTED attributes are valid, and bonding uses them to clear the ARP and NS target lists. When either target attribute is empty, nla_for_each_nested() does not execute, so err retains an uninitialized value before it is tested. The request can consequently return an unpredictable error after clearing the targets. Initialize err to zero so an empty target list completes successfully. Non-empty lists still propagate errors from __bond_opt_set() unchanged. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 4fb0ef5 ("bonding: convert arp_ip_target to use the new option API") Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn> Link: https://patch.msgid.link/20260813153126.3952893-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0b1c2af ] sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95 ("net: add net device refcount tracker infrastructure") added ref_tracker_dir_exit() to only free_netdev() path. Closes: https://sashiko.dev/#/patchset/56c707e7-1fb0-43ec-b8fb-cf6f451e513e%40I-love.SAKURA.ne.jp Fixes: 4d92b95 ("net: add net device refcount tracker infrastructure") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/b06ce35d-e7bc-47a5-8e0a-e82be7e4dd08@I-love.SAKURA.ne.jp Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 281eb47 ] The page reporting callback submits an sg list to the reporting virtqueue. With VIRTIO_RING_F_INDIRECT_DESC negotiated and total_sg > 1 (which it typically is), virtqueue_add reports it to the host by allocating an indirect descriptor via kmalloc(GFP_KERNEL). This is not pretty: the reporting worker isolates potentially hundreds of MB of free pages from the buddy allocator (reported pages are at least pageblock_order, and the sg can contain up to PAGE_REPORTING_CAPACITY entries of varying orders). As the result, very theoretically, the kmalloc might trigger OOM when we have in fact a ton of free memory. Clear VIRTIO_RING_F_INDIRECT_DESC, to avoid using indirect descriptors. Fixes: b0c504f ("virtio-balloon: add support for providing free page reports to host") Assisted-by: Claude:claude-opus-4-6 Acked-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <73fac8a629fd9aca7bb3265ac243a769c28af25d.1783232420.git.mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bd670e5 ] vdpasim_create() leaves vdpasim->worker as an ERR_PTR when kthread_run_worker() fails. The error path then drops the device reference, which releases the partially initialized simulator. vdpasim_free() unconditionally passes the worker pointer to kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger a general protection fault. Store the worker error, clear the pointer, and only clean up the worker when it was successfully initialized. Also make the release path tolerate partially initialized objects by guarding virtqueue and IOTLB cleanup, since the same release path can be reached from other initialization failures. I found this bug myself, though the patch was written with AI assistance. Fixes: 76acfa7 ("vdpa_sim: use kthread worker") Assisted-by: OpenAI-Codex:GPT-5 Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Linfeng Sun <linfeng.sun.dev@gamil.com> Message-ID: <20260620100959.2070316-1-slf@hdu.edu.cn> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0d8aebe ] The generic virtio bus .shutdown handler, virtio_dev_shutdown(), breaks and resets a device once it has established that the driver has no .shutdown of its own. A driver that does implement .shutdown, to quiesce its own activity first, still needs the same break and reset afterwards and would otherwise have to open code it. Factor the break + synchronize_cbs + reset sequence out of virtio_dev_shutdown() into an exported virtio_device_shutdown() helper so such drivers can reuse it instead of duplicating the core logic. No functional change. Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260624140846.2616797-2-den@openvz.org> Stable-dep-of: 7e17eef ("virtio_balloon: quiesce balloon work before device shutdown") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 29536a9 ] virtballoon_remove() stops all of the balloon's asynchronous work (the free page reporting worker, the inflate/deflate and stats workers, the OOM notifier and the free page shrinker) before tearing the device down. A following change needs the same teardown from a .shutdown handler, so move it into a virtballoon_quiesce() helper. No functional change. Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260624140846.2616797-3-den@openvz.org> Stable-dep-of: 7e17eef ("virtio_balloon: quiesce balloon work before device shutdown") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e17eef ] Commit 8bd2fa0 ("virtio: break and reset virtio devices on device_shutdown()") added a generic virtio bus .shutdown handler that breaks and resets every virtio device during device_shutdown(), i.e. on reboot and kexec. virtio_balloon provides no .shutdown of its own, so that generic path runs while the balloon's asynchronous work is still armed. Once the device has been broken, virtqueue_add_inbuf() in virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an ordinary reboot, for example a kexec based upgrade, into a fatal panic in the middle of device_shutdown(), so the machine never reaches the new kernel. Relaxing that single WARN_ON_ONCE() would only hide the symptom: the inflate/deflate and OOM paths do not warn, they call wait_event(vb->acked, ...) and would instead block forever on a broken queue that can no longer complete. The device has to be quiesced, not just kept quiet. Add a .shutdown handler that quiesces the balloon via the shared virtballoon_quiesce() helper while the device is still alive, and only then breaks and resets it via virtio_device_shutdown(). Unlike virtballoon_remove() the balloon workqueue is not destroyed, as shutdown does not free the device and cancel_work_sync() together with stop_update already prevent any further work from being queued. Fixes: 8bd2fa0 ("virtio: break and reset virtio devices on device_shutdown()") Signed-off-by: Denis V. Lunev <den@openvz.org> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260624140846.2616797-4-den@openvz.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 92a7b13 ] The clear_user() call in VHOST_GET_FEATURES_ARRAY incorrectly starts at argp, which is the beginning of the features array, overwriting the data just written by copy_to_user(). It should start after the copied elements at argp + copied * sizeof(u64) to only zero the trailing unused space. Use size_mul() for both the offset and length calculations so the arithmetic stays consistent with the surrounding code and remains overflow-safe. Fixes: 333c515 ("vhost-net: allow configuring extended features") Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn> Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260626070438.59149-1-r4o5m6e8o@163.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit dc3f1ee ] In vp_find_vqs_intx(), the admin vq was set up using the local queue_idx counter instead of avq->vq_index (the actual queue index obtained from the device). This differs from vp_find_vqs_msix() which correctly uses avq->vq_index. Using the wrong index causes the admin virtqueue to be mapped to an incorrect hardware queue. Fix it by using avq->vq_index consistent with the msix path. Fixes: af22bbe ("virtio: create admin queues alongside other virtqueues") Signed-off-by: Li RongQing <lirongqing@baidu.com> Message-ID: <20260629033538.2476-1-lirongqing@baidu.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 23ae56d ] In add_direct_chain(), newly allocated direct MR entries are added to the local list 'tmp', which is spliced into mr->head only on success. On the error path, the cleanup loop was incorrectly iterating over mr->head instead of tmp. Fix by iterating over 'tmp' in the err_alloc cleanup path. Fixes: 94abbcc ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: Li RongQing <lirongqing@baidu.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260701113608.1972-1-lirongqing@baidu.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 68e00d9 ] RTC class operations run with rtc_device.ops_lock held. The virtio RTC alarm requests currently wait without a timeout for the device to return their requestq buffers. On surprise removal, virtio-pci marks the virtqueues broken before unregistering the virtio device. If an alarm request is waiting when the device stops responding, viortc_remove() blocks in viortc_class_stop() while trying to acquire ops_lock. The request cannot complete and device removal hangs until the waiting task is signalled. Use the same 60-second timeout as clock read requests for alarm reads, alarm programming, and alarm interrupt enable requests. The existing message reference counting keeps a timed-out request alive until a late response or device teardown. Fixes: 9d4f22f ("virtio_rtc: Add RTC class driver") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn> Reviewed-by: Peter Hilber <peter.hilber@oss.qualcomm.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260714024352.71307-1-zhaoguohan@kylinos.cn> Signed-off-by: Sasha Levin <sashal@kernel.org>
Test Matrix
|
Test Matrix
|
Test Matrix
|
Test Matrix
|
🔨 Build Failure Analysis — PR #1158PR: #1158
VerdictThe single build error is pre-existing and not introduced by this PR. The PR does not modify or add any interconnect nodes at address 0x2a0c0000. 📎 Detailed analysis: Full report |
PR #1158 — validate-patchPR: #1158
Final Summary
Note: The validate-patch skill is designed for discrete patches with lore.kernel.org attribution. Stable kernel merges require a different validation workflow focused on version verification, build testing, and regression checking rather than per-patch lore attribution.
|
PR #1158 — checker-log-analyzerPR: #1158
Detailed report: Full report
|
🔨 Build Failure Analysis — PR #1158PR: #1158
VerdictThe single build error is pre-existing and not introduced by this PR. The PR does not modify the code region where the error occurs. 📎 Detailed analysis: Full report |
PR #1158 — validate-patchPR: #1158
Final Summary
|
PR #1158 — checker-log-analyzerPR: #1158
Detailed report: Full report
|
Test Matrix
|
PR #1158 — validate-patchPR: #1158
Final Summary
|
PR #1158 — checker-log-analyzerPR: #1158
Detailed report: Full report
|
🔨 Build Failure Analysis — PR #1158PR: #1158
VerdictNo build failures detected. The kernel compiled successfully for both standard and RT configurations. The workflow failure was caused by LAVA test job submission failures, not compilation errors. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158
VerdictNo compilation errors detected. Both the main kernel build and RT kernel build completed successfully. The workflow failure was caused by LAVA test job submission failures, not compilation issues. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158 Build Status: ✅ SUCCESSBoth the standard kernel build and RT kernel build completed successfully with no compilation errors. Workflow Failure Root CauseThe workflow was marked as failed due to LAVA test submission failures, not build failures.
Error Details:
VerdictNo compilation errors were introduced by this PR. The workflow failure is entirely due to infrastructure issues with the LAVA test server, which is unrelated to the code changes in the PR. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158 VerdictNo compilation errors found. The kernel builds (both standard and RT) completed successfully. The workflow failure was caused by LAVA test job submission failures, not build errors. Build Status:
Root Cause: The workflow was marked as failed because LAVA job submissions did not return numeric job IDs, indicating a test infrastructure problem rather than a compilation or code quality issue introduced by this PR. Recommendation: The PR changes are safe from a compilation perspective. The test submission failures should be investigated separately as an infrastructure issue. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158
VerdictThe build completed successfully. The workflow failure was caused by LAVA test job submission failures (infrastructure issue), not by compilation errors. All kernel builds (both standard and RT) completed without errors. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158 Build Status: ✅ SUCCESSBoth the standard and RT kernel builds completed successfully with no compilation errors.
Test Status: ❌ FAILED (Infrastructure Issue)All 10 LAVA test submissions failed due to infrastructure connectivity issues, not due to code problems.
Error Message (all platforms): Verdict0 compilation errors found. The PR introduces no build failures. All kernel builds completed successfully. The workflow failure was caused by LAVA test infrastructure connectivity issues (connection timeouts to lava-oss.qualcomm.com), not by any code changes in the PR. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158
VerdictNo compilation errors found. The kernel build completed successfully. The workflow failure was caused by a LAVA test infrastructure timeout ( 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158 Build Status: ✅ ALL BUILDS PASSEDThe kernel compilation completed successfully for all target configurations:
Test Status: ❌ ALL TESTS FAILEDAll LAVA test jobs failed due to infrastructure timeout, not code issues:
VerdictZero compilation errors. The workflow failure is caused by LAVA test infrastructure timeout, not by any code changes in this PR. All kernel builds completed successfully. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158 ✅ Build Status: SUCCESSThe kernel compilation completed successfully for both standard and RT builds. No compilation errors were detected. ❌ Workflow Failure Cause: Test Submission TimeoutThe workflow was marked as failed due to LAVA test job submission failures, not build errors. All test jobs failed with:
VerdictNo compilation errors found. The PR builds cleanly. The workflow failure is due to infrastructure issues (LAVA server connectivity), not code problems introduced by this PR. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1158PR: #1158
VerdictThe kernel build completed successfully with no compilation errors. The workflow failure was caused by LAVA test job submission failures (infrastructure issue), not by build errors. This PR updates the stable kernel from v6.18.44 to v6.18.52. 📎 Detailed analysis: Full report |
CR:4702380