commit f964b940099f9982d723d4c77988d4b0dda9c165
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Dec 7 06:08:24 2025 +0900

    Linux 5.10.247
    
    Link: https://lore.kernel.org/r/20251203152400.447697997@linuxfoundation.org
    Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20251204163803.668231017@linuxfoundation.org
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Brett A C Sheffield <bacs@librecast.net>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8164d0efaf370c425dc69a1e8216940d09e7de0c
Author: Florian Westphal <fw@strlen.de>
Date:   Fri May 23 14:20:44 2025 +0200

    netfilter: nf_set_pipapo_avx2: fix initial map fill
    
    commit ea77c397bff8b6d59f6d83dae1425b08f465e8b5 upstream.
    
    If the first field doesn't cover the entire start map, then we must zero
    out the remainder, else we leak those bits into the next match round map.
    
    The early fix was incomplete and did only fix up the generic C
    implementation.
    
    A followup patch adds a test case to nft_concat_range.sh.
    
    Fixes: 791a615b7ad2 ("netfilter: nf_set_pipapo: fix initial map fill")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f77618291836168eca99e89cd175256f928f5e64
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Tue Dec 2 12:03:16 2025 +0000

    ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up
    
    [ Upstream commit c84e125fff2615b4d9c259e762596134eddd2f27 ]
    
    The issue was caused by dput(upper) being called before
    ovl_dentry_update_reval(), while upper->d_flags was still
    accessed in ovl_dentry_remote().
    
    Move dput(upper) after its last use to prevent use-after-free.
    
    BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]
    BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167
    
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0xc3/0x620 mm/kasan/report.c:488
     kasan_report+0xd9/0x110 mm/kasan/report.c:601
     ovl_dentry_remote fs/overlayfs/util.c:162 [inline]
     ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167
     ovl_link_up fs/overlayfs/copy_up.c:610 [inline]
     ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170
     ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223
     ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136
     vfs_rename+0xf84/0x20a0 fs/namei.c:4893
    ...
     </TASK>
    
    Fixes: b07d5cc93e1b ("ovl: update of dentry revalidate flags after copy up")
    Reported-by: syzbot+316db8a1191938280eb6@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=316db8a1191938280eb6
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20250214215148.761147-1-kovalev@altlinux.org
    Reviewed-by: Amir Goldstein <amir73il@gmail.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    [ Minor context change fixed. ]
    Signed-off-by: Bin Lan <lanbincn@qq.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6289fc489e94c9beb6be2b502ccc263663733d72
Author: Owen Gu <guhuinan@xiaomi.com>
Date:   Mon Dec 1 20:48:40 2025 -0500

    usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer
    
    [ Upstream commit 26d56a9fcb2014b99e654127960aa0a48a391e3c ]
    
    When a UAS device is unplugged during data transfer, there is
    a probability of a system panic occurring. The root cause is
    an access to an invalid memory address during URB callback handling.
    Specifically, this happens when the dma_direct_unmap_sg() function
    is called within the usb_hcd_unmap_urb_for_dma() interface, but the
    sg->dma_address field is 0 and the sg data structure has already been
    freed.
    
    The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()
    in uas.c, using the uas_submit_urbs() function to submit requests to USB.
    Within the uas_submit_urbs() implementation, three URBs (sense_urb,
    data_urb, and cmd_urb) are sequentially submitted. Device removal may
    occur at any point during uas_submit_urbs execution, which may result
    in URB submission failure. However, some URBs might have been successfully
    submitted before the failure, and uas_submit_urbs will return the -ENODEV
    error code in this case. The current error handling directly calls
    scsi_done(). In the SCSI driver, this eventually triggers scsi_complete()
    to invoke scsi_end_request() for releasing the sgtable. The successfully
    submitted URBs, when being unlinked to giveback, call
    usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg
    unmapping operations since the sg data structure has already been freed.
    
    This patch modifies the error condition check in the uas_submit_urbs()
    function. When a UAS device is removed but one or more URBs have already
    been successfully submitted to USB, it avoids immediately invoking
    scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully
    submitted URBs is completed before devinfo->resetting being set, then
    the scsi_done() function will be called within uas_try_complete() after
    all pending URB operations are finalized. Otherwise, the scsi_done()
    function will be called within uas_zap_pending(), which is executed after
    usb_kill_anchored_urbs().
    
    The error handling only takes effect when uas_queuecommand_lck() calls
    uas_submit_urbs() and returns the error value -ENODEV . In this case,
    the device is disconnected, and the flow proceeds to uas_disconnect(),
    where uas_zap_pending() is invoked to call uas_try_complete().
    
    Fixes: eb2a86ae8c54 ("USB: UAS: fix disconnect by unplugging a hub")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Yu Chen <chenyu45@xiaomi.com>
    Signed-off-by: Owen Gu <guhuinan@xiaomi.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Link: https://patch.msgid.link/20251120123336.3328-1-guhuinan@xiaomi.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [ adapted scsi_done(cmnd) helper to older cmnd->scsi_done(cmnd) callback API ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd1a7bf3a8cac13f6d2d52d8c7570ba41621db9a
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Date:   Mon Dec 1 20:27:36 2025 -0500

    usb: renesas_usbhs: Fix synchronous external abort on unbind
    
    [ Upstream commit eb9ac779830b2235847b72cb15cf07c7e3333c5e ]
    
    A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is
    executed after the configuration sequence described above:
    
    modprobe usb_f_ecm
    modprobe libcomposite
    modprobe configfs
    cd /sys/kernel/config/usb_gadget
    mkdir -p g1
    cd g1
    echo "0x1d6b" > idVendor
    echo "0x0104" > idProduct
    mkdir -p strings/0x409
    echo "0123456789" > strings/0x409/serialnumber
    echo "Renesas." > strings/0x409/manufacturer
    echo "Ethernet Gadget" > strings/0x409/product
    mkdir -p functions/ecm.usb0
    mkdir -p configs/c.1
    mkdir -p configs/c.1/strings/0x409
    echo "ECM" > configs/c.1/strings/0x409/configuration
    
    if [ ! -L configs/c.1/ecm.usb0 ]; then
            ln -s functions/ecm.usb0 configs/c.1
    fi
    
    echo 11e20000.usb > UDC
    echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind
    
    The displayed trace is as follows:
    
     Internal error: synchronous external abort: 0000000096000010 [#1] SMP
     CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT
     Tainted: [M]=MACHINE_CHECK
     Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT)
     pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs]
     lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs]
     sp : ffff8000838b3920
     x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000
     x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810
     x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000
     x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020
     x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344
     x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000
     x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418
     x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d
     x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000
     x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80
     Call trace:
     usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P)
     usbhsg_pullup+0x4c/0x7c [renesas_usbhs]
     usb_gadget_disconnect_locked+0x48/0xd4
     gadget_unbind_driver+0x44/0x114
     device_remove+0x4c/0x80
     device_release_driver_internal+0x1c8/0x224
     device_release_driver+0x18/0x24
     bus_remove_device+0xcc/0x10c
     device_del+0x14c/0x404
     usb_del_gadget+0x88/0xc0
     usb_del_gadget_udc+0x18/0x30
     usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs]
     usbhs_mod_remove+0x20/0x30 [renesas_usbhs]
     usbhs_remove+0x98/0xdc [renesas_usbhs]
     platform_remove+0x20/0x30
     device_remove+0x4c/0x80
     device_release_driver_internal+0x1c8/0x224
     device_driver_detach+0x18/0x24
     unbind_store+0xb4/0xb8
     drv_attr_store+0x24/0x38
     sysfs_kf_write+0x7c/0x94
     kernfs_fop_write_iter+0x128/0x1b8
     vfs_write+0x2ac/0x350
     ksys_write+0x68/0xfc
     __arm64_sys_write+0x1c/0x28
     invoke_syscall+0x48/0x110
     el0_svc_common.constprop.0+0xc0/0xe0
     do_el0_svc+0x1c/0x28
     el0_svc+0x34/0xf0
     el0t_64_sync_handler+0xa0/0xe4
     el0t_64_sync+0x198/0x19c
     Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021)
     ---[ end trace 0000000000000000 ]---
     note: sh[188] exited with irqs disabled
     note: sh[188] exited with preempt_count 1
    
    The issue occurs because usbhs_sys_function_pullup(), which accesses the IP
    registers, is executed after the USBHS clocks have been disabled. The
    problem is reproducible on the Renesas RZ/G3S SoC starting with the
    addition of module stop in the clock enable/disable APIs. With module stop
    functionality enabled, a bus error is expected if a master accesses a
    module whose clock has been stopped and module stop activated.
    
    Disable the IP clocks at the end of remove.
    
    Cc: stable <stable@kernel.org>
    Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code")
    Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
    Link: https://patch.msgid.link/20251027140741.557198-1-claudiu.beznea.uj@bp.renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b376d6cbfa393833d83aadcbb310d976aa26a5f
Author: Jameson Thies <jthies@google.com>
Date:   Mon Dec 1 20:06:19 2025 -0500

    usb: typec: ucsi: psy: Set max current to zero when disconnected
    
    [ Upstream commit 23379a17334fc24c4a9cbd9967d33dcd9323cc7c ]
    
    The ucsi_psy_get_current_max function defaults to 0.1A when it is not
    clear how much current the partner device can support. But this does
    not check the port is connected, and will report 0.1A max current when
    nothing is connected. Update ucsi_psy_get_current_max to report 0A when
    there is no connection.
    
    Fixes: af833e7f7db3 ("usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jameson Thies <jthies@google.com>
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Tested-by: Kenneth R. Crudup <kenny@panix.com>
    Rule: add
    Link: https://lore.kernel.org/stable/20251017000051.2094101-1-jthies%40google.com
    Link: https://patch.msgid.link/20251106011446.2052583-1-jthies@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [ adapted UCSI_CONSTAT() macro to direct flag access ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff8f9bd1c46ee02d5558293915d42e82646d5ee9
Author: Paulo Alcantara <pc@manguebit.org>
Date:   Mon Dec 1 17:24:51 2025 -0500

    smb: client: fix memory leak in cifs_construct_tcon()
    
    [ Upstream commit 3184b6a5a24ec9ee74087b2a550476f386df7dc2 ]
    
    When having a multiuser mount with domain= specified and using
    cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,
    so it needs to be freed before leaving cifs_construct_tcon().
    
    This fixes the following memory leak reported by kmemleak:
    
      mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...
      su - testuser
      cifscreds add -d ZELDA -u testuser
      ...
      ls /mnt/1
      ...
      umount /mnt
      echo scan > /sys/kernel/debug/kmemleak
      cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffff8881203c3f08 (size 8):
        comm "ls", pid 5060, jiffies 4307222943
        hex dump (first 8 bytes):
          5a 45 4c 44 41 00 cc cc                          ZELDA...
        backtrace (crc d109a8cf):
          __kmalloc_node_track_caller_noprof+0x572/0x710
          kstrdup+0x3a/0x70
          cifs_sb_tlink+0x1209/0x1770 [cifs]
          cifs_get_fattr+0xe1/0xf50 [cifs]
          cifs_get_inode_info+0xb5/0x240 [cifs]
          cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]
          cifs_getattr+0x28e/0x450 [cifs]
          vfs_getattr_nosec+0x126/0x180
          vfs_statx+0xf6/0x220
          do_statx+0xab/0x110
          __x64_sys_statx+0xd5/0x130
          do_syscall_64+0xbb/0x380
          entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: f2aee329a68f ("cifs: set domainName when a domain-key is used in multiuser")
    Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
    Reviewed-by: David Howells <dhowells@redhat.com>
    Cc: Jay Shin <jaeshin@redhat.com>
    Cc: stable@vger.kernel.org
    Cc: linux-cifs@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    [ Different path + ctx -> vol_info ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92c4092fe012ecdfa5fb05d394f1c1d8f91ad81c
Author: Jiayuan Chen <jiayuan.chen@linux.dev>
Date:   Mon Dec 1 12:34:58 2025 +0100

    mptcp: Fix proto fallback detection with BPF
    
    commit c77b3b79a92e3345aa1ee296180d1af4e7031f8f upstream.
    
    The sockmap feature allows bpf syscall from userspace, or based
    on bpf sockops, replacing the sk_prot of sockets during protocol stack
    processing with sockmap's custom read/write interfaces.
    '''
    tcp_rcv_state_process()
      syn_recv_sock()/subflow_syn_recv_sock()
        tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
          bpf_skops_established       <== sockops
            bpf_sock_map_update(sk)   <== call bpf helper
              tcp_bpf_update_proto()  <== update sk_prot
    '''
    
    When the server has MPTCP enabled but the client sends a TCP SYN
    without MPTCP, subflow_syn_recv_sock() performs a fallback on the
    subflow, replacing the subflow sk's sk_prot with the native sk_prot.
    '''
    subflow_syn_recv_sock()
      subflow_ulp_fallback()
        subflow_drop_ctx()
          mptcp_subflow_ops_undo_override()
    '''
    
    Then, this subflow can be normally used by sockmap, which replaces the
    native sk_prot with sockmap's custom sk_prot. The issue occurs when the
    user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
    Here, it uses sk->sk_prot to compare with the native sk_prot, but this
    is incorrect when sockmap is used, as we may incorrectly set
    sk->sk_socket->ops.
    
    This fix uses the more generic sk_family for the comparison instead.
    
    Additionally, this also prevents a WARNING from occurring:
    
    result from ./scripts/decode_stacktrace.sh:
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
    (net/mptcp/protocol.c:4005)
    Modules linked in:
    ...
    
    PKRU: 55555554
    Call Trace:
    <TASK>
    do_accept (net/socket.c:1989)
    __sys_accept4 (net/socket.c:2028 net/socket.c:2057)
    __x64_sys_accept (net/socket.c:2067)
    x64_sys_call (arch/x86/entry/syscall_64.c:41)
    do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    RIP: 0033:0x7f87ac92b83d
    
    ---[ end trace 0000000000000000 ]---
    
    Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
    Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
    [ Conflicts in protocol.c, because commit 8e2b8a9fa512 ("mptcp: don't
      overwrite sock_ops in mptcp_is_tcpsk()") is not in this version. It
      changes the logic on how and where the sock_ops is overridden in case
      of passive fallback. To fix this, mptcp_is_tcpsk() is modified to use
      the family, but first, a check of the protocol is required to continue
      returning 'false' in case of MPTCP socket. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ddc501f4130f4baa787cb6cfa309af697179f475
Author: Igor Pylypiv <ipylypiv@google.com>
Date:   Fri Nov 28 17:48:15 2025 +0300

    scsi: pm80xx: Set phy->enable_completion only when we
    
    [ Upstream commit e4f949ef1516c0d74745ee54a0f4882c1f6c7aea ]
    
    pm8001_phy_control() populates the enable_completion pointer with a stack
    address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and
    returns. The problem arises when a phy control response comes late.  After
    300 ms the pm8001_phy_control() function returns and the passed
    enable_completion stack address is no longer valid. Late phy control
    response invokes complete() on a dangling enable_completion pointer which
    leads to a kernel crash.
    
    Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
    Signed-off-by: Terrence Adams <tadamsjr@google.com>
    Link: https://lore.kernel.org/r/20240627155924.2361370-2-tadamsjr@google.com
    Acked-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Nazar Kalashnikov <sivartiwe@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77bf0c4ab928ca4c9a99311f4f70ba0c17fecba9
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Nov 28 17:46:01 2025 +0300

    netfilter: nf_set_pipapo: fix initial map fill
    
    [ Upstream commit 791a615b7ad2258c560f91852be54b0480837c93 ]
    
    The initial buffer has to be inited to all-ones, but it must restrict
    it to the size of the first field, not the total field size.
    
    After each round in the map search step, the result and the fill map
    are swapped, so if we have a set where f->bsize of the first element
    is smaller than m->bsize_max, those one-bits are leaked into future
    rounds result map.
    
    This makes pipapo find an incorrect matching results for sets where
    first field size is not the largest.
    
    Followup patch adds a test case to nft_concat_range.sh selftest script.
    
    Thanks to Stefano Brivio for pointing out that we need to zero out
    the remainder explicitly, only correcting memset() argument isn't enough.
    
    Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges")
    Reported-by: Yi Chen <yiche@redhat.com>
    Cc: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Nazar Kalashnikov <sivartiwe@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2cec30f0a244a603b21c405bd3b04ae0a3cd53a
Author: Alex Lu <alex_lu@realsil.com.cn>
Date:   Fri Nov 28 17:45:34 2025 +0300

    Bluetooth: Add more enc key size check
    
    [ Upstream commit 04a342cc49a8522e99c9b3346371c329d841dcd2 ]
    
    When we are slave role and receives l2cap conn req when encryption has
    started, we should check the enc key size to avoid KNOB attack or BLUFFS
    attack.
    >From SIG recommendation, implementations are advised to reject
    service-level connections on an encrypted baseband link with key
    strengths below 7 octets.
    A simple and clear way to achieve this is to place the enc key size
    check in hci_cc_read_enc_key_size()
    
    The btmon log below shows the case that lacks enc key size check.
    
    > HCI Event: Connect Request (0x04) plen 10
            Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Class: 0x480104
              Major class: Computer (desktop, notebook, PDA, organizers)
              Minor class: Desktop workstation
              Capturing (Scanner, Microphone)
              Telephony (Cordless telephony, Modem, Headset)
            Link type: ACL (0x01)
    < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
            Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Role: Peripheral (0x01)
    > HCI Event: Command Status (0x0f) plen 4
          Accept Connection Request (0x01|0x0009) ncmd 2
            Status: Success (0x00)
    > HCI Event: Connect Complete (0x03) plen 11
            Status: Success (0x00)
            Handle: 1
            Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Link type: ACL (0x01)
            Encryption: Disabled (0x00)
    ...
    
    > HCI Event: Encryption Change (0x08) plen 4
            Status: Success (0x00)
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Encryption: Enabled with E0 (0x01)
    < HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
    > HCI Event: Command Complete (0x0e) plen 7
          Read Encryption Key Size (0x05|0x0008) ncmd 2
            Status: Success (0x00)
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Key size: 6
    // We should check the enc key size
    ...
    
    > ACL Data RX: Handle 1 flags 0x02 dlen 12
          L2CAP: Connection Request (0x02) ident 3 len 4
            PSM: 25 (0x0019)
            Source CID: 64
    < ACL Data TX: Handle 1 flags 0x00 dlen 16
          L2CAP: Connection Response (0x03) ident 3 len 8
            Destination CID: 64
            Source CID: 64
            Result: Connection pending (0x0001)
            Status: Authorization pending (0x0002)
    > HCI Event: Number of Completed Packets (0x13) plen 5
            Num handles: 1
            Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33)
            Count: 1
            #35: len 16 (25 Kb/s)
            Latency: 5 msec (2-7 msec ~4 msec)
    < ACL Data TX: Handle 1 flags 0x00 dlen 16
          L2CAP: Connection Response (0x03) ident 3 len 8
            Destination CID: 64
            Source CID: 64
            Result: Connection successful (0x0000)
            Status: No further information available (0x0000)
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
    Signed-off-by: Max Chou <max.chou@realtek.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    [ Nazar Kalashnikov: change status to
    rp_status due to function parameter conflict ]
    Signed-off-by: Nazar Kalashnikov <sivartiwe@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2a14bbae5d8bacaa301362744a110e2be40a3a3
Author: Jiufei Xue <jiufei.xue@samsung.com>
Date:   Fri Nov 28 17:41:19 2025 +0300

    fs: writeback: fix use-after-free in __mark_inode_dirty()
    
    [ Upstream commit d02d2c98d25793902f65803ab853b592c7a96b29 ]
    
    An use-after-free issue occurred when __mark_inode_dirty() get the
    bdi_writeback that was in the progress of switching.
    
    CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1
    ......
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __mark_inode_dirty+0x124/0x418
    lr : __mark_inode_dirty+0x118/0x418
    sp : ffffffc08c9dbbc0
    ........
    Call trace:
     __mark_inode_dirty+0x124/0x418
     generic_update_time+0x4c/0x60
     file_modified+0xcc/0xd0
     ext4_buffered_write_iter+0x58/0x124
     ext4_file_write_iter+0x54/0x704
     vfs_write+0x1c0/0x308
     ksys_write+0x74/0x10c
     __arm64_sys_write+0x1c/0x28
     invoke_syscall+0x48/0x114
     el0_svc_common.constprop.0+0xc0/0xe0
     do_el0_svc+0x1c/0x28
     el0_svc+0x40/0xe4
     el0t_64_sync_handler+0x120/0x12c
     el0t_64_sync+0x194/0x198
    
    Root cause is:
    
    systemd-random-seed                         kworker
    ----------------------------------------------------------------------
    ___mark_inode_dirty                     inode_switch_wbs_work_fn
    
      spin_lock(&inode->i_lock);
      inode_attach_wb
      locked_inode_to_wb_and_lock_list
         get inode->i_wb
         spin_unlock(&inode->i_lock);
         spin_lock(&wb->list_lock)
      spin_lock(&inode->i_lock)
      inode_io_list_move_locked
      spin_unlock(&wb->list_lock)
      spin_unlock(&inode->i_lock)
                                        spin_lock(&old_wb->list_lock)
                                          inode_do_switch_wbs
                                            spin_lock(&inode->i_lock)
                                            inode->i_wb = new_wb
                                            spin_unlock(&inode->i_lock)
                                        spin_unlock(&old_wb->list_lock)
                                        wb_put_many(old_wb, nr_switched)
                                          cgwb_release
                                          old wb released
      wb_wakeup_delayed() accesses wb,
      then trigger the use-after-free
      issue
    
    Fix this race condition by holding inode spinlock until
    wb_wakeup_delayed() finished.
    
    Signed-off-by: Jiufei Xue <jiufei.xue@samsung.com>
    Link: https://lore.kernel.org/20250728100715.3863241-1-jiufei.xue@samsung.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Nazar Kalashnikov <sivartiwe@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb4910c5fd436701faf367e1b5476a5a6d2aff1c
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Nov 3 21:34:01 2025 +0100

    libceph: fix potential use-after-free in have_mon_and_osd_map()
    
    commit 076381c261374c587700b3accf410bdd2dba334e upstream.
    
    The wait loop in __ceph_open_session() can race with the client
    receiving a new monmap or osdmap shortly after the initial map is
    received.  Both ceph_monc_handle_map() and handle_one_map() install
    a new map immediately after freeing the old one
    
        kfree(monc->monmap);
        monc->monmap = monmap;
    
        ceph_osdmap_destroy(osdc->osdmap);
        osdc->osdmap = newmap;
    
    under client->monc.mutex and client->osdc.lock respectively, but
    because neither is taken in have_mon_and_osd_map() it's possible for
    client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in
    
        client->monc.monmap && client->monc.monmap->epoch &&
            client->osdc.osdmap && client->osdc.osdmap->epoch;
    
    condition to dereference an already freed map.  This happens to be
    reproducible with generic/395 and generic/397 with KASAN enabled:
    
        BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
        Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
        CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
        ...
        Call Trace:
        <TASK>
        have_mon_and_osd_map+0x56/0x70
        ceph_open_session+0x182/0x290
        ceph_get_tree+0x333/0x680
        vfs_get_tree+0x49/0x180
        do_new_mount+0x1a3/0x2d0
        path_mount+0x6dd/0x730
        do_mount+0x99/0xe0
        __do_sys_mount+0x141/0x180
        do_syscall_64+0x9f/0x100
        entry_SYSCALL_64_after_hwframe+0x76/0x7e
        </TASK>
    
        Allocated by task 13305:
        ceph_osdmap_alloc+0x16/0x130
        ceph_osdc_init+0x27a/0x4c0
        ceph_create_client+0x153/0x190
        create_fs_client+0x50/0x2a0
        ceph_get_tree+0xff/0x680
        vfs_get_tree+0x49/0x180
        do_new_mount+0x1a3/0x2d0
        path_mount+0x6dd/0x730
        do_mount+0x99/0xe0
        __do_sys_mount+0x141/0x180
        do_syscall_64+0x9f/0x100
        entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
        Freed by task 9475:
        kfree+0x212/0x290
        handle_one_map+0x23c/0x3b0
        ceph_osdc_handle_map+0x3c9/0x590
        mon_dispatch+0x655/0x6f0
        ceph_con_process_message+0xc3/0xe0
        ceph_con_v1_try_read+0x614/0x760
        ceph_con_workfn+0x2de/0x650
        process_one_work+0x486/0x7c0
        process_scheduled_works+0x73/0x90
        worker_thread+0x1c8/0x2a0
        kthread+0x2ec/0x300
        ret_from_fork+0x24/0x40
        ret_from_fork_asm+0x1a/0x30
    
    Rewrite the wait loop to check the above condition directly with
    client->monc.mutex and client->osdc.lock taken as appropriate.  While
    at it, improve the timeout handling (previously mount_timeout could be
    exceeded in case wait_event_interruptible_timeout() slept more than
    once) and access client->auth_err under client->monc.mutex to match
    how it's set in finish_auth().
    
    monmap_show() and osdmap_show() now take the respective lock before
    accessing the map as well.
    
    Cc: stable@vger.kernel.org
    Reported-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 781f2f32e9c19eb791b52af283c96f9a9677a7f2
Author: Alex Hung <alex.hung@amd.com>
Date:   Fri Nov 7 15:35:58 2025 -0700

    drm/amd/display: Check NULL before accessing
    
    commit 3ce62c189693e8ed7b3abe551802bbc67f3ace54 upstream.
    
    [WHAT]
    IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic
    fails with NULL pointer dereference. This can be reproduced with
    both an eDP panel and a DP monitors connected.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: Oops: 0000 [#1] SMP NOPTI
     CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted
    6.16.0-99-custom #8 PREEMPT(voluntary)
     Hardware name: AMD ........
     RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu]
     Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49
     89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30
     c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02
     RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292
     RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668
     RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000
     RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760
     R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000
     R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c
     FS:  000071f631b68700(0000) GS:ffff8b399f114000(0000)
    knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0
     PKRU: 55555554
     Call Trace:
     <TASK>
     dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu]
     amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu]
     ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu]
     amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu]
     drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400
     drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30
     drm_crtc_get_last_vbltimestamp+0x55/0x90
     drm_crtc_next_vblank_start+0x45/0xa0
     drm_atomic_helper_wait_for_fences+0x81/0x1f0
     ...
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75d528ee11776e7437e053bf30a5dccf6b681248
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Sep 22 14:20:12 2025 +0200

    drm: sti: fix device leaks at component probe
    
    commit 620a8f131154250f6a64a07d049a4f235d6451a5 upstream.
    
    Make sure to drop the references taken to the vtg devices by
    of_find_device_by_node() when looking up their driver data during
    component probe.
    
    Note that holding a reference to a platform device does not prevent its
    driver data from going away so there is no point in keeping the
    reference after the lookup helper returns.
    
    Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure")
    Cc: stable@vger.kernel.org      # 4.16
    Cc: Benjamin Gaignard <benjamin.gaignard@collabora.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20250922122012.27407-1-johan@kernel.org
    Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 664e575ffa9c5074e8a7e5a2705670f006cc18a0
Author: Vanillan Wang <vanillanwang@163.com>
Date:   Mon Nov 10 12:20:41 2025 +0800

    USB: serial: option: add support for Rolling RW101R-GL
    
    commit 523bf0a59e674b52e4b5607a2aba655fbfa20ff2 upstream.
    
    - VID:PID 33f8:0301, RW101R-GL for laptop debug M.2 cards (with MBIM
      interface for Linux/Chrome OS)
    
      0x0301: mbim, pipe
    
    T:  Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0301 Rev=05.04
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling RW101R-GL Module
    S:  SerialNumber=3ec4efdf
    C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    - VID:PID 33f8:01a8, RW101R-GL for laptop debug M.2 cards (with MBIM
      interface for Linux/Chrome OS)
    
      0x01a8: mbim, diag, AT, ADB, pipe1, pipe2
    
    T:  Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=33f8 ProdID=01a8 Rev=05.04
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling RW101R-GL Module
    S:  SerialNumber=3ec4efdf
    C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=89(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    - VID:PID 33f8:0302, RW101R-GL for laptop debug M.2 cards (with MBIM
      interface for Linux/Chrome OS)
    
      0x0302: mbim, pipe
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=33f8 ProdID=0302 Rev=05.04
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling RW101R-GL Module
    S:  SerialNumber=3ec4efdf
    C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    - VID:PID 33f8:01a9, RW101R-GL for laptop debug M.2 cards (with MBIM
      interface for Linux/Chrome OS)
    
      0x01a9: mbim, diag, AT, ADB, pipe1, pipe2
    
    T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=33f8 ProdID=01a9 Rev=05.04
    S:  Manufacturer=Rolling Wireless S.a.r.l.
    S:  Product=Rolling RW101R-GL Module
    S:  SerialNumber=3ec4efdf
    C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    Signed-off-by: Vanillan Wang <vanillanwang@163.com>
    Cc: stable@vger.kernel.org
    [ johan: sort vendor entries, edit commit message slightly ]
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 955c2bd2165627c194d9958f9eda2c0144695f3b
Author: Oleksandr Suvorov <cryosay@gmail.com>
Date:   Thu Oct 30 17:42:54 2025 +0200

    USB: serial: ftdi_sio: add support for u-blox EVK-M101
    
    commit 2d8ab771d5316de64f3bb920b82575c58eb00b1b upstream.
    
    The U-Blox EVK-M101 enumerates as 1546:0506 [1] with four FTDI interfaces:
    - EVK-M101 current sensors
    - EVK-M101 I2C
    - EVK-M101 UART
    - EVK-M101 port D
    
    Only the third USB interface is a UART. This change lets ftdi_sio probe
    the VID/PID and registers only interface #3 as a TTY, leaving the rest
    available for other drivers.
    
    [1]
    usb 5-1.3: new high-speed USB device number 11 using xhci_hcd
    usb 5-1.3: New USB device found, idVendor=1546, idProduct=0506, bcdDevice= 8.00
    usb 5-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 5-1.3: Product: EVK-M101
    usb 5-1.3: Manufacturer: u-blox AG
    
    Datasheet: https://content.u-blox.com/sites/default/files/documents/EVK-M10_UserGuide_UBX-21003949.pdf
    
    Signed-off-by: Oleksandr Suvorov <cryosay@gmail.com>
    Link: https://lore.kernel.org/20250926060235.3442748-1-cryosay@gmail.com/
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bef1f6bb0c76bb1d928ff77e15c3c1bc1c8b45ff
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Nov 7 18:28:17 2025 +0200

    xhci: dbgtty: Fix data corruption when transmitting data form DbC to host
    
    commit f6bb3b67be9af0cfb90075c60850b6af5338a508 upstream.
    
    Data read from a DbC device may be corrupted due to a race between
    ongoing write and write request completion handler both queuing new
    transfer blocks (TRBs) if there are remining data in the kfifo.
    
    TRBs may be in incorrct order compared to the data in the kfifo.
    
    Driver fails to keep lock between reading data from kfifo into a
    dbc request buffer, and queuing the request to the transfer ring.
    
    This allows completed request to re-queue itself in the middle of
    an ongoing transfer loop, forcing itself between a kfifo read and
    request TRB write of another request
    
    cpu0                                    cpu1 (re-queue completed req2)
    
    lock(port_lock)
    dbc_start_tx()
    kfifo_out(fifo, req1->buffer)
    unlock(port_lock)
                                            lock(port_lock)
                                            dbc_write_complete(req2)
                                            dbc_start_tx()
                                            kfifo_out(fifo, req2->buffer)
                                            unlock(port_lock)
                                            lock(port_lock)
                                            req2->trb = ring->enqueue;
                                            ring->enqueue++
                                            unlock(port_lock)
    lock(port_lock)
    req1->trb = ring->enqueue;
    ring->enqueue++
    unlock(port_lock)
    
    In the above scenario a kfifo containing "12345678" would read "1234" to
    req1 and "5678" to req2, but req2 is queued before req1 leading to
    data being transmitted as "56781234"
    
    Solve this by adding a flag that prevents starting a new tx if we
    are already mid dbc_start_tx() during the unlocked part.
    
    The already running dbc_do_start_tx() will make sure the newly completed
    request gets re-queued as it is added to the request write_pool while
    holding the lock.
    
    Cc: stable@vger.kernel.org
    Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
    Tested-by: Łukasz Bartosik <ukaszb@chromium.org>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://patch.msgid.link/20251107162819.1362579-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 467add9db13219101f14b6cc5477998b4aaa5fe2
Author: Manish Nagar <manish.nagar@oss.qualcomm.com>
Date:   Thu Nov 20 13:14:35 2025 +0530

    usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths
    
    commit e4037689a366743c4233966f0e74bc455820d316 upstream.
    
    This patch addresses a race condition caused by unsynchronized
    execution of multiple call paths invoking `dwc3_remove_requests()`,
    leading to premature freeing of USB requests and subsequent crashes.
    
    Three distinct execution paths interact with `dwc3_remove_requests()`:
    Path 1:
    Triggered via `dwc3_gadget_reset_interrupt()` during USB reset
    handling. The call stack includes:
    - `dwc3_ep0_reset_state()`
    - `dwc3_ep0_stall_and_restart()`
    - `dwc3_ep0_out_start()`
    - `dwc3_remove_requests()`
    - `dwc3_gadget_del_and_unmap_request()`
    
    Path 2:
    Also initiated from `dwc3_gadget_reset_interrupt()`, but through
    `dwc3_stop_active_transfers()`. The call stack includes:
    - `dwc3_stop_active_transfers()`
    - `dwc3_remove_requests()`
    - `dwc3_gadget_del_and_unmap_request()`
    
    Path 3:
    Occurs independently during `adb root` execution, which triggers
    USB function unbind and bind operations. The sequence includes:
    - `gserial_disconnect()`
    - `usb_ep_disable()`
    - `dwc3_gadget_ep_disable()`
    - `dwc3_remove_requests()` with `-ESHUTDOWN` status
    
    Path 3 operates asynchronously and lacks synchronization with Paths
    1 and 2. When Path 3 completes, it disables endpoints and frees 'out'
    requests. If Paths 1 or 2 are still processing these requests,
    accessing freed memory leads to a crash due to use-after-free conditions.
    
    To fix this added check for request completion and skip processing
    if already completed and added the request status for ep0 while queue.
    
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Cc: stable <stable@kernel.org>
    Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Manish Nagar <manish.nagar@oss.qualcomm.com>
    Link: https://patch.msgid.link/20251120074435.1983091-1-manish.nagar@oss.qualcomm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d00a6c04a502cd52425dbf35588732c652b16490
Author: Tianchu Chen <flynnnchen@tencent.com>
Date:   Sun Nov 16 12:46:18 2025 +0800

    usb: storage: sddr55: Reject out-of-bound new_pba
    
    commit b59d4fda7e7d0aff1043a7f742487cb829f5aac1 upstream.
    
    Discovered by Atuin - Automated Vulnerability Discovery Engine.
    
    new_pba comes from the status packet returned after each write.
    A bogus device could report values beyond the block count derived
    from info->capacity, letting the driver walk off the end of
    pba_to_lba[] and corrupt heap memory.
    
    Reject PBAs that exceed the computed block count and fail the
    transfer so we avoid touching out-of-range mapping entries.
    
    Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
    Cc: stable <stable@kernel.org>
    Link: https://patch.msgid.link/B2DC73A3EE1E3A1D+202511161322001664687@tencent.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cd5f4b421aec93708ba7c1fcbbff74366e28fdd
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Nov 21 16:29:34 2025 -0500

    USB: storage: Remove subclass and protocol overrides from Novatek quirk
    
    commit df5fde297e617041449f603ed5f646861c80000b upstream.
    
    A report from Oleg Smirnov indicates that the unusual_devs quirks
    entry for the Novatek camera does not need to override the subclass
    and protocol parameters:
    
    [3266355.209532] usb 1-3: new high-speed USB device number 10 using xhci_hcd
    [3266355.333031] usb 1-3: New USB device found, idVendor=0603, idProduct=8611, bcdDevice= 1.00
    [3266355.333040] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [3266355.333043] usb 1-3: Product: YICARCAM
    [3266355.333045] usb 1-3: Manufacturer: XIAO-YI
    [3266355.333047] usb 1-3: SerialNumber: 966110000000100
    [3266355.338621] usb-storage 1-3:1.0: USB Mass Storage device detected
    [3266355.338817] usb-storage 1-3:1.0: Quirks match for vid 0603 pid 8611: 4000
    [3266355.338821] usb-storage 1-3:1.0: This device (0603,8611,0100 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h (kernel 6.16.10-arch1-1)
                        Please send a copy of this message to
    <linux-usb@vger.kernel.org> and <usb-storage@lists.one-eyed-alien.net>
    
    The overrides are harmless but they do provoke the driver into logging
    this annoying message.  Update the entry to remove the unneeded entries.
    
    Reported-by: stealth <oleg.smirnov.1988@gmail.com>
    Closes: https://lore.kernel.org/CAKxjRRxhC0s19iEWoN=pEMqXJ_z8w_moC0GCXSqSKCcOddnWjQ@mail.gmail.com/
    Fixes: 6ca8af3c8fb5 ("USB: storage: Add unusual-devs entry for Novatek NTK96550-based camera")
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@kernel.org>
    Link: https://patch.msgid.link/b440f177-f0b8-4d5a-8f7b-10855d4424ee@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83f0241959831586d9b6d47f6bd5d3dec8f43bf0
Author: Desnes Nunes <desnesn@redhat.com>
Date:   Fri Oct 31 01:34:36 2025 -0300

    usb: storage: Fix memory leak in USB bulk transport
    
    commit 41e99fe2005182139b1058db71f0d241f8f0078c upstream.
    
    A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
    Test Project (LTP). The following bytes were mainly observed: 0x53425355.
    
    When USB storage devices incorrectly skip the data phase with status data,
    the code extracts/validates the CSW from the sg buffer, but fails to clear
    it afterwards. This leaves status protocol data in srb's transfer buffer,
    such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
    lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
    interfaces, such as the one seen here when the LTP test requested 512 KiB.
    
    Fix the leak by zeroing the CSW data in srb's transfer buffer immediately
    after the validation of devices that skip data phase.
    
    Note: Differently from CVE-2018-1000204, which fixed a big leak by zero-
    ing pages at allocation time, this leak occurs after allocation, when USB
    protocol data is written to already-allocated sg pages.
    
    Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Desnes Nunes <desnesn@redhat.com>
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://patch.msgid.link/20251031043436.55929-1-desnesn@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9985a88b2fc29fbe1657fe8518908e261d6889c
Author: Kuen-Han Tsai <khtsai@google.com>
Date:   Mon Nov 3 20:17:59 2025 +0800

    usb: gadget: f_eem: Fix memory leak in eem_unwrap
    
    commit e4f5ce990818d37930cd9fb0be29eee0553c59d9 upstream.
    
    The existing code did not handle the failure case of usb_ep_queue in the
    command path, potentially leading to memory leaks.
    
    Improve error handling to free all allocated resources on usb_ep_queue
    failure. This patch continues to use goto logic for error handling, as the
    existing error handling is complex and not easily adaptable to auto-cleanup
    helpers.
    
    kmemleak results:
      unreferenced object 0xffffff895a512300 (size 240):
        backtrace:
          slab_post_alloc_hook+0xbc/0x3a4
          kmem_cache_alloc+0x1b4/0x358
          skb_clone+0x90/0xd8
          eem_unwrap+0x1cc/0x36c
      unreferenced object 0xffffff8a157f4000 (size 256):
        backtrace:
          slab_post_alloc_hook+0xbc/0x3a4
          __kmem_cache_alloc_node+0x1b4/0x2dc
          kmalloc_trace+0x48/0x140
          dwc3_gadget_ep_alloc_request+0x58/0x11c
          usb_ep_alloc_request+0x40/0xe4
          eem_unwrap+0x204/0x36c
      unreferenced object 0xffffff8aadbaac00 (size 128):
        backtrace:
          slab_post_alloc_hook+0xbc/0x3a4
          __kmem_cache_alloc_node+0x1b4/0x2dc
          __kmalloc+0x64/0x1a8
          eem_unwrap+0x218/0x36c
      unreferenced object 0xffffff89ccef3500 (size 64):
        backtrace:
          slab_post_alloc_hook+0xbc/0x3a4
          __kmem_cache_alloc_node+0x1b4/0x2dc
          kmalloc_trace+0x48/0x140
          eem_unwrap+0x238/0x36c
    
    Fixes: 4249d6fbc10f ("usb: gadget: eem: fix echo command packet response issue")
    Cc: stable@kernel.org
    Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
    Link: https://patch.msgid.link/20251103121814.1559719-1-khtsai@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c159f645c6da2b30ed2effdb5dc2a906c979ca2b
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Oct 26 17:08:59 2025 +0800

    usb: cdns3: Fix double resource release in cdns3_pci_probe
    
    commit 1ec39d2cd88dac2e7cdbac248762f1f057971c5d upstream.
    
    The driver uses pcim_enable_device() to enable the PCI device,
    the device will be automatically disabled on driver detach through
    the managed device framework. The manual pci_disable_device() calls
    in the error paths are therefore redundant and should be removed.
    
    Found via static anlaysis and this is similar to commit 99ca0b57e49f
    ("thermal: intel: int340x: processor: Fix warning during module unload").
    
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://patch.msgid.link/20251026090859.33107-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90e6ce2b1b19fb8b9d4afee69f40e4c6a4791154
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Oct 29 10:30:29 2025 +0100

    most: usb: fix double free on late probe failure
    
    commit baadf2a5c26e802a46573eaad331b427b49aaa36 upstream.
    
    The MOST subsystem has a non-standard registration function which frees
    the interface on registration failures and on deregistration.
    
    This unsurprisingly leads to bugs in the MOST drivers, and a couple of
    recent changes turned a reference underflow and use-after-free in the
    USB driver into several double free and a use-after-free on late probe
    failures.
    
    Fixes: 723de0f9171e ("staging: most: remove device from interface structure")
    Fixes: 4b1270902609 ("most: usb: Fix use-after-free in hdm_disconnect")
    Fixes: a8cc9e5fcb0e ("most: usb: hdm_probe: Fix calling put_device() before device initialization")
    Cc: stable@vger.kernel.org
    Cc: Christian Gromm <christian.gromm@microchip.com>
    Cc: Victoria Votokina <Victoria.Votokina@kaspersky.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://patch.msgid.link/20251029093029.28922-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16336cc676a5d49eeb231644f61ce7c7850addc2
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Oct 27 17:20:50 2025 +0800

    serial: amba-pl011: prefer dma_mapping_error() over explicit address checking
    
    commit eb4917f557d43c7a1c805dd73ffcdfddb2aba39a upstream.
    
    Check for returned DMA addresses using specialized dma_mapping_error()
    helper which is generally recommended for this purpose by
    Documentation/core-api/dma-api.rst:
    
      "In some circumstances dma_map_single(), ...
    will fail to create a mapping. A driver can check for these errors
    by testing the returned DMA address with dma_mapping_error()."
    
    Found via static analysis and this is similar to commit fa0308134d26
    ("ALSA: memalloc: prefer dma_mapping_error() over explicit address checking")
    
    Fixes: 58ac1b379979 ("ARM: PL011: Fix DMA support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Link: https://patch.msgid.link/20251027092053.87937-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d0a330abd9e49bcebf6307aac185081bde49a43
Author: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
Date:   Mon Nov 3 07:21:28 2025 +0800

    firmware: stratix10-svc: fix bug in saving controller data
    
    commit d0fcf70c680e4d1669fcb3a8632f41400b9a73c2 upstream.
    
    Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They
    both are of the same data and overrides each other. This resulted in the
    rmmod of the svc driver to fail and throw a kernel panic for kthread_stop
    and fifo free.
    
    Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features")
    Cc: stable@vger.kernel.org # 6.6+
    Signed-off-by: Ang Tien Sung <tiensung.ang@altera.com>
    Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b2db3eb6ad5492c70b834e78ac28d3166c4e289
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Oct 27 14:06:01 2025 +0800

    slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves
    
    commit 96cf8500934e0ce2a6c486f1dbc3b1fff12f7a5e upstream.
    
    The function qcom_slim_ngd_notify_slaves() calls of_slim_get_device() which
    internally uses device_find_child() to obtain a device reference.
    According to the device_find_child() documentation,
    the caller must drop the reference with put_device() after use.
    
    Found via static analysis and this is similar to commit 4e65bda8273c
    ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()")
    
    Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Link: https://patch.msgid.link/20251027060601.33228-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4d66ea76843ef8421f90c8d3480acde572b5044
Author: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Date:   Thu Nov 14 10:55:44 2024 +0100

    thunderbolt: Add support for Intel Wildcat Lake
    
    commit 3575254546a27210a4b661ea37fbbfb836c0815d upstream.
    
    Intel Wildcat Lake derives its Thunderbolt/USB4 controller from Lunar
    Lake platform. Add Wildcat Lake PCI ID to the driver list of supported
    devices.
    
    Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 295b169a10186c3d8e5529ed8e544f7993c6f6e6
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Nov 17 21:42:02 2025 +0100

    dm-verity: fix unreliable memory allocation
    
    commit fe680d8c747f4e676ac835c8c7fb0f287cd98758 upstream.
    
    GFP_NOWAIT allocation may fail anytime. It needs to be changed to
    GFP_NOIO. There's no need to handle an error because mempool_alloc with
    GFP_NOIO can't fail.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Eric Biggers <ebiggers@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6dfc11c4df38a218e77684b1e72c4f7252069d6a
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Sun Nov 16 16:55:26 2025 +0100

    can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling
    
    commit 76544beea7cfe5bcce6d60f53811657b88ec8be1 upstream.
    
    Reading the interrupt register `SUN4I_REG_INT_ADDR` causes all of its bits
    to be reset. If we ever reach the condition of handling more than
    `SUN4I_CAN_MAX_IRQ` IRQs, we will have read the register and reset all its
    bits but without actually handling the interrupt inside of the loop body.
    
    This may, among other issues, cause us to never `netif_wake_queue()` again
    after a transmission interrupt.
    
    Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
    Cc: stable@vger.kernel.org
    Co-developed-by: Thomas Mühlbacher <tmuehlbacher@posteo.net>
    Signed-off-by: Thomas Mühlbacher <tmuehlbacher@posteo.net>
    Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://patch.msgid.link/20251116-sun4i-fix-loop-v1-1-3d76d3f81950@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 259192ecbe93453eaa0e4fafab056c1bb91afbf4
Author: Thomas Mühlbacher <tmuehlbacher@posteo.net>
Date:   Sat Nov 15 15:34:56 2025 +0000

    can: sja1000: fix max irq loop handling
    
    commit 30db4451c7f6aabcada029b15859a76962ec0cf8 upstream.
    
    Reading the interrupt register `SJA1000_IR` causes all of its bits to be
    reset. If we ever reach the condition of handling more than
    `SJA1000_MAX_IRQ` IRQs, we will have read the register and reset all its
    bits but without actually handling the interrupt inside of the loop
    body.
    
    This may, among other issues, cause us to never `netif_wake_queue()`
    again after a transmission interrupt.
    
    Fixes: 429da1cc841b ("can: Driver for the SJA1000 CAN controller")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Mühlbacher <tmuehlbacher@posteo.net>
    Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Link: https://patch.msgid.link/20251115153437.11419-1-tmuehlbacher@posteo.net
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b60f42a639999c37da7f1fbfa1ad29cf4cbdd2d
Author: Gui-Dong Han <hanguidong02@gmail.com>
Date:   Thu Nov 20 20:06:57 2025 +0800

    atm/fore200e: Fix possible data race in fore200e_open()
    
    commit 82fca3d8a4a34667f01ec2351a607135249c9cff upstream.
    
    Protect access to fore200e->available_cell_rate with rate_mtx lock in the
    error handling path of fore200e_open() to prevent a data race.
    
    The field fore200e->available_cell_rate is a shared resource used to track
    available bandwidth. It is concurrently accessed by fore200e_open(),
    fore200e_close(), and fore200e_change_qos().
    
    In fore200e_open(), the lock rate_mtx is correctly held when subtracting
    vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.
    However, if the subsequent call to fore200e_activate_vcin() fails, the
    function restores the reserved bandwidth by adding back to
    available_cell_rate without holding the lock.
    
    This introduces a race condition because available_cell_rate is a global
    device resource shared across all VCCs. If the error path in
    fore200e_open() executes concurrently with operations like
    fore200e_close() or fore200e_change_qos() on other VCCs, a
    read-modify-write race occurs.
    
    Specifically, the error path reads the rate without the lock. If another
    CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in
    fore200e_close()) between this read and the subsequent write, the error
    path will overwrite the concurrent update with a stale value. This results
    in incorrect bandwidth accounting.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20251120120657.2462194-1-hanguidong02@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 57206652186e5f5ad9d087f8eeea879366685a52
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Thu Nov 13 05:21:10 2025 +0000

    MIPS: mm: Prevent a TLB shutdown on initial uniquification
    
    commit 9f048fa487409e364cf866c957cf0b0d782ca5a3 upstream.
    
    Depending on the particular CPU implementation a TLB shutdown may occur
    if multiple matching entries are detected upon the execution of a TLBP
    or the TLBWI/TLBWR instructions.  Given that we don't know what entries
    we have been handed we need to be very careful with the initial TLB
    setup and avoid all these instructions.
    
    Therefore read all the TLB entries one by one with the TLBR instruction,
    bypassing the content addressing logic, and truncate any large pages in
    place so as to avoid a case in the second step where an incoming entry
    for a large page at a lower address overlaps with a replacement entry
    chosen at another index.  Then preinitialize the TLB using addresses
    outside our usual unique range and avoiding clashes with any entries
    received, before making the usual call to local_flush_tlb_all().
    
    This fixes (at least) R4x00 cores if TLBP hits multiple matching TLB
    entries (SGI IP22 PROM for examples sets up all TLBs to the same virtual
    address).
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
    Cc: stable@vger.kernel.org
    Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com> # Boston I6400, M5150 sim
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a692e295a037602ac9258d5185fdb1a9b577357
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Oct 10 20:58:48 2025 +0200

    iio:common:ssp_sensors: Fix an error handling path ssp_probe()
    
    commit 21553258b94861a73d7f2cf15469d69240e1170d upstream.
    
    If an error occurs after a successful mfd_add_devices() call, it should be
    undone by a corresponding mfd_remove_devices() call, as already done in the
    remove function.
    
    Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Nuno Sá <nuno.sa@analog.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7959c7c0513eea1d7b00b14eff9a582979d881aa
Author: Francesco Lavra <flavra@baylibre.com>
Date:   Fri Oct 17 19:32:08 2025 +0200

    iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields
    
    commit 3af0c1fb1cdc351b64ff1a4bc06d491490c1f10a upstream.
    
    The `decimator` and `batch` fields of struct st_lsm6dsx_settings
    are arrays indexed by sensor type, not by sensor hardware
    identifier; moreover, the `batch` field is only used for the
    accelerometer and gyroscope.
    Change the array size for `decimator` from ST_LSM6DSX_MAX_ID to
    ST_LSM6DSX_ID_MAX, and change the array size for `batch` from
    ST_LSM6DSX_MAX_ID to 2; move the enum st_lsm6dsx_sensor_id
    definition so that the ST_LSM6DSX_ID_MAX value is usable within
    the struct st_lsm6dsx_settings definition.
    
    Fixes: 801a6e0af0c6c ("iio: imu: st_lsm6dsx: add support to LSM6DSO")
    Signed-off-by: Francesco Lavra <flavra@baylibre.com>
    Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebd13c15dd378c8b489bd689ef70a494804df752
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Tue Nov 4 22:54:02 2025 +0100

    Revert "perf/x86: Always store regs->ip in perf_callchain_kernel()"
    
    commit 6d08340d1e354787d6c65a8c3cdd4d41ffb8a5ed upstream.
    
    This reverts commit 83f44ae0f8afcc9da659799db8693f74847e66b3.
    
    Currently we store initial stacktrace entry twice for non-HW ot_regs, which
    means callers that fail perf_hw_regs(regs) condition in perf_callchain_kernel.
    
    It's easy to reproduce this bpftrace:
    
      # bpftrace -e 'tracepoint:sched:sched_process_exec { print(kstack()); }'
      Attaching 1 probe...
    
            bprm_execve+1767
            bprm_execve+1767
            do_execveat_common.isra.0+425
            __x64_sys_execve+56
            do_syscall_64+133
            entry_SYSCALL_64_after_hwframe+118
    
    When perf_callchain_kernel calls unwind_start with first_frame, AFAICS
    we do not skip regs->ip, but it's added as part of the unwind process.
    Hence reverting the extra perf_callchain_store for non-hw regs leg.
    
    I was not able to bisect this, so I'm not really sure why this was needed
    in v5.2 and why it's not working anymore, but I could see double entries
    as far as v5.10.
    
    I did the test for both ORC and framepointer unwind with and without the
    this fix and except for the initial entry the stacktraces are the same.
    
    Acked-by: Song Liu <song@kernel.org>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20251104215405.168643-2-jolsa@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 320fa9b6b9fbb7764c5909d76dd9a66da72df021
Author: Hang Zhou <929513338@qq.com>
Date:   Mon Nov 17 01:08:35 2025 +1100

    spi: bcm63xx: fix premature CS deassertion on RX-only transactions
    
    [ Upstream commit fd9862f726aedbc2f29a29916cabed7bcf5cadb6 ]
    
    On BCM6358 (and also observed on BCM6368) the controller appears to
    only generate as many SPI clocks as bytes that have been written into
    the TX FIFO. For RX-only transfers the driver programs the transfer
    length in SPI_MSG_CTL but does not write anything into the FIFO, so
    chip select is deasserted early and the RX transfer segment is never
    fully clocked in.
    
    A concrete failing case is a three-transfer MAC address read from
    SPI-NOR:
      - TX 0x03 (read command)
      - TX 3-byte address
      - RX 6 bytes (MAC)
    
    In contrast, a two-transfer JEDEC-ID read (0x9f + 6-byte RX) works
    because the driver uses prepend_len and writes dummy bytes into the
    TX FIFO for the RX part.
    
    Fix this by writing 0xff dummy bytes into the TX FIFO for RX-only
    segments so that the number of bytes written to the FIFO matches the
    total message length seen by the controller.
    
    Fixes: b17de076062a ("spi/bcm63xx: work around inability to keep CS up")
    
    Signed-off-by: Hang Zhou <929513338@qq.com>
    Link: https://patch.msgid.link/tencent_7AC88FCB3076489A4A7E6C2163DF1ACF8D06@qq.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d5307f3aef334ead09be4c73e2db23261174dc4
Author: Haotian Zhang <vulab@iscas.ac.cn>
Date:   Thu Nov 20 10:40:39 2025 +0800

    mailbox: mailbox-test: Fix debugfs_create_dir error checking
    
    [ Upstream commit 3acf1028f5003731977f750a7070f3321a9cb740 ]
    
    The debugfs_create_dir() function returns ERR_PTR() on error, not NULL.
    The current null-check fails to catch errors.
    
    Use IS_ERR() to correctly check for errors.
    
    Fixes: 8ea4484d0c2b ("mailbox: Add generic mechanism for testing Mailbox Controllers")
    Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
    Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34147477eeab24077fcfe9649e282849347d760c
Author: Jiefeng Zhang <jiefeng.z.zhang@gmail.com>
Date:   Wed Nov 26 11:22:49 2025 +0800

    net: atlantic: fix fragment overflow handling in RX path
    
    [ Upstream commit 5ffcb7b890f61541201461580bb6622ace405aec ]
    
    The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)
    fragments when handling large multi-descriptor packets. This causes an
    out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.
    
    The issue occurs because the driver doesn't check the total number of
    fragments before calling skb_add_rx_frag(). When a packet requires more
    than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.
    
    Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,
    then all fragments are accounted for. And reusing the existing check to
    prevent the overflow earlier in the code path.
    
    This crash occurred in production with an Aquantia AQC113 10G NIC.
    
    Stack trace from production environment:
    ```
    RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0
    Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89
    ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90
    c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48
    89 fa 83
    RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287
    RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:
    fffffffe0a0c8000
    RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:
    0000000000037a40
    RBP: 0000000000000024 R08: 0000000000000000 R09:
    0000000000000021
    R10: 0000000000000848 R11: 0000000000000000 R12:
    ffffa9bec02a8e24
    R13: ffff925ad8615570 R14: 0000000000000000 R15:
    ffff925b22e80a00
    FS: 0000000000000000(0000)
    GS:ffff925e47880000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:
    0000000000f72ef0
    PKRU: 55555554
    Call Trace:
    <IRQ>
    aq_ring_rx_clean+0x175/0xe60 [atlantic]
    ? aq_ring_rx_clean+0x14d/0xe60 [atlantic]
    ? aq_ring_tx_clean+0xdf/0x190 [atlantic]
    ? kmem_cache_free+0x348/0x450
    ? aq_vec_poll+0x81/0x1d0 [atlantic]
    ? __napi_poll+0x28/0x1c0
    ? net_rx_action+0x337/0x420
    ```
    
    Fixes: 6aecbba12b5c ("net: atlantic: add check for MAX_SKB_FRAGS")
    Changes in v4:
    - Add Fixes: tag to satisfy patch validation requirements.
    
    Changes in v3:
    - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,
      then all fragments are accounted for.
    
    Signed-off-by: Jiefeng Zhang <jiefeng.z.zhang@gmail.com>
    Link: https://patch.msgid.link/20251126032249.69358-1-jiefeng.z.zhang@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac171c3c755499c9f87fe30b920602255f8b5648
Author: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Date:   Fri Nov 21 12:38:34 2025 +0000

    net: sxgbe: fix potential NULL dereference in sxgbe_rx()
    
    [ Upstream commit f5bce28f6b9125502abec4a67d68eabcd24b3b17 ]
    
    Currently, when skb is null, the driver prints an error and then
    dereferences skb on the next line.
    
    To fix this, let's add a 'break' after the error message to switch
    to sxgbe_rx_refill(), which is similar to the approach taken by the
    other drivers in this particular case, e.g. calxeda with xgmac_rx().
    
    Found during a code review.
    
    Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver")
    Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20251121123834.97748-1-aleksei.kodanev@bell-sw.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 10c16687513e6f7270f1709f9aacd80f5471dc8c
Author: Danielle Costantino <dcostantino@meta.com>
Date:   Mon Nov 24 10:00:43 2025 -0800

    net/mlx5e: Fix validation logic in rate limiting
    
    [ Upstream commit d2099d9f16dbfa1c5266d4230ff7860047bb0b68 ]
    
    The rate limiting validation condition currently checks the output
    variable max_bw_value[i] instead of the input value
    maxrate->tc_maxrate[i]. This causes the validation to compare an
    uninitialized or stale value rather than the actual requested rate.
    
    The condition should check the input rate to properly validate against
    the upper limit:
    
        } else if (maxrate->tc_maxrate[i] <= upper_limit_gbps) {
    
    This aligns with the pattern used in the first branch, which correctly
    checks maxrate->tc_maxrate[i] against upper_limit_mbps.
    
    The current implementation can lead to unreliable validation behavior:
    
    - For rates between 25.5 Gbps and 255 Gbps, if max_bw_value[i] is 0
      from initialization, the GBPS path may be taken regardless of whether
      the actual rate is within bounds
    
    - When processing multiple TCs (i > 0), max_bw_value[i] contains the
      value computed for the previous TC, affecting the validation logic
    
    - The overflow check for rates exceeding 255 Gbps may not trigger
      consistently depending on previous array values
    
    This patch ensures the validation correctly examines the requested rate
    value for proper bounds checking.
    
    Fixes: 43b27d1bd88a ("net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps")
    Signed-off-by: Danielle Costantino <dcostantino@meta.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Link: https://patch.msgid.link/20251124180043.2314428-1-dcostantino@meta.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7ae9de8595908d5bd993684e39ace4c3f03f9bc4
Author: Kai-Heng Feng <kaihengf@nvidia.com>
Date:   Thu Nov 20 12:15:33 2025 +0800

    net: aquantia: Add missing descriptor cache invalidation on ATL2
    
    [ Upstream commit 7526183cfdbe352c51c285762f0e15b7c428ea06 ]
    
    ATL2 hardware was missing descriptor cache invalidation in hw_stop(),
    causing SMMU translation faults during device shutdown and module removal:
    [   70.355743] arm-smmu-v3 arm-smmu-v3.5.auto: event 0x10 received:
    [   70.361893] arm-smmu-v3 arm-smmu-v3.5.auto:  0x0002060000000010
    [   70.367948] arm-smmu-v3 arm-smmu-v3.5.auto:  0x0000020000000000
    [   70.374002] arm-smmu-v3 arm-smmu-v3.5.auto:  0x00000000ff9bc000
    [   70.380055] arm-smmu-v3 arm-smmu-v3.5.auto:  0x0000000000000000
    [   70.386109] arm-smmu-v3 arm-smmu-v3.5.auto: event: F_TRANSLATION client: 0001:06:00.0 sid: 0x20600 ssid: 0x0 iova: 0xff9bc000 ipa: 0x0
    [   70.398531] arm-smmu-v3 arm-smmu-v3.5.auto: unpriv data write s1 "Input address caused fault" stag: 0x0
    
    Commit 7a1bb49461b1 ("net: aquantia: fix potential IOMMU fault after
    driver unbind") and commit ed4d81c4b3f2 ("net: aquantia: when cleaning
    hw cache it should be toggled") fixed cache invalidation for ATL B0, but
    ATL2 was left with only interrupt disabling. This allowed hardware to
    write to cached descriptors after DMA memory was unmapped, triggering
    SMMU faults. Once cache invalidation is applied to ATL2, the translation
    fault can't be observed anymore.
    
    Add shared aq_hw_invalidate_descriptor_cache() helper and use it in both
    ATL B0 and ATL2 hw_stop() implementations for consistent behavior.
    
    Fixes: e54dcf4bba3e ("net: atlantic: basic A2 init/deinit hw_ops")
    Tested-by: Carol Soto <csoto@nvidia.com>
    Signed-off-by: Kai-Heng Feng <kaihengf@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20251120041537.62184-1-kaihengf@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dceb5b49a73758c93729ceefd9dae9bba96c9ce1
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Nov 17 13:45:13 2025 -0500

    Bluetooth: SMP: Fix not generating mackey and ltk when repairing
    
    [ Upstream commit 545d7827b2cd5de5eb85580cebeda6b35b3ff443 ]
    
    The change eed467b517e8 ("Bluetooth: fix passkey uninitialized when used")
    introduced a goto that bypasses the creation of temporary mackey and ltk
    which are later used by the likes of DHKey Check step.
    
    Later ffee202a78c2 ("Bluetooth: Always request for user confirmation for
    Just Works (LE SC)") which means confirm_hint is always set in case
    JUST_WORKS so the branch checking for an existing LTK becomes pointless
    as confirm_hint will always be set, so this just merge both cases of
    malicious or legitimate devices to be confirmed before continuing with the
    pairing procedure.
    
    Link: https://github.com/bluez/bluez/issues/1622
    Fixes: eed467b517e8 ("Bluetooth: fix passkey uninitialized when used")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58343e0a4d43699f0e2f5b169384bbe4c0217add
Author: Seungjin Bae <eeodqql09@gmail.com>
Date:   Thu Oct 23 12:27:09 2025 -0400

    can: kvaser_usb: leaf: Fix potential infinite loop in command parsers
    
    [ Upstream commit 0c73772cd2b8cc108d5f5334de89ad648d89b9ec ]
    
    The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`
    functions contain logic to zero-length commands. These commands are used
    to align data to the USB endpoint's wMaxPacketSize boundary.
    
    The driver attempts to skip these placeholders by aligning the buffer
    position `pos` to the next packet boundary using `round_up()` function.
    
    However, if zero-length command is found exactly on a packet boundary
    (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`
    function will return the unchanged value of `pos`. This prevents `pos`
    to be increased, causing an infinite loop in the parsing logic.
    
    This patch fixes this in the function by using `pos + 1` instead.
    This ensures that even if `pos` is on a boundary, the calculation is
    based on `pos + 1`, forcing `round_up()` to always return the next
    aligned boundary.
    
    Fixes: 7259124eac7d ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c")
    Signed-off-by: Seungjin Bae <eeodqql09@gmail.com>
    Reviewed-by: Jimmy Assarsson <extja@kvaser.com>
    Tested-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://patch.msgid.link/20251023162709.348240-1-eeodqql09@gmail.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36bc92b838ff72f62f2c17751a9013b29ead2513
Author: Seungjin Bae <eeodqql09@gmail.com>
Date:   Mon Nov 24 13:57:18 2025 -0500

    Input: pegasus-notetaker - fix potential out-of-bounds access
    
    [ Upstream commit 69aeb507312306f73495598a055293fa749d454e ]
    
    In the pegasus_notetaker driver, the pegasus_probe() function allocates
    the URB transfer buffer using the wMaxPacketSize value from
    the endpoint descriptor. An attacker can use a malicious USB descriptor
    to force the allocation of a very small buffer.
    
    Subsequently, if the device sends an interrupt packet with a specific
    pattern (e.g., where the first byte is 0x80 or 0x42),
    the pegasus_parse_packet() function parses the packet without checking
    the allocated buffer size. This leads to an out-of-bounds memory access.
    
    Fixes: 1afca2b66aac ("Input: add Pegasus Notetaker tablet driver")
    Signed-off-by: Seungjin Bae <eeodqql09@gmail.com>
    Link: https://lore.kernel.org/r/20251007214131.3737115-2-eeodqql09@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0032d1cb75f7e3d73726015cbd1e7a5ab9b7d727
Author: Vincent Mailhol <mailhol@kernel.org>
Date:   Mon Nov 24 13:57:17 2025 -0500

    Input: remove third argument of usb_maxpacket()
    
    [ Upstream commit 948bf187694fc1f4c20cf972fa18b1a6fb3d7603 ]
    
    The third argument of usb_maxpacket(): in_out has been deprecated
    because it could be derived from the second argument (e.g. using
    usb_pipeout(pipe)).
    
    N.B. function usb_maxpacket() was made variadic to accommodate the
    transition from the old prototype with three arguments to the new one
    with only two arguments (so that no renaming is needed). The variadic
    argument is to be removed once all users of usb_maxpacket() get
    migrated.
    
    CC: Ville Syrjala <syrjala@sci.fi>
    CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    CC: Henk Vergonet <Henk.Vergonet@gmail.com>
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Link: https://lore.kernel.org/r/20220317035514.6378-4-mailhol.vincent@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 69aeb5073123 ("Input: pegasus-notetaker - fix potential out-of-bounds access")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38c4f5dd915b16e2a57989216ed2a8966d9de004
Author: Vincent Mailhol <mailhol@kernel.org>
Date:   Mon Nov 24 13:57:16 2025 -0500

    usb: deprecate the third argument of usb_maxpacket()
    
    [ Upstream commit 0f08c2e7458e25c967d844170f8ad1aac3b57a02 ]
    
    This is a transitional patch with the ultimate goal of changing the
    prototype of usb_maxpacket() from:
    | static inline __u16
    | usb_maxpacket(struct usb_device *udev, int pipe, int is_out)
    
    into:
    | static inline u16 usb_maxpacket(struct usb_device *udev, int pipe)
    
    The third argument of usb_maxpacket(): is_out gets removed because it
    can be derived from its second argument: pipe using
    usb_pipeout(pipe). Furthermore, in the current version,
    ubs_pipeout(pipe) is called regardless in order to sanitize the is_out
    parameter.
    
    In order to make a smooth change, we first deprecate the is_out
    parameter by simply ignoring it (using a variadic function) and will
    remove it later, once all the callers get updated.
    
    The body of the function is reworked accordingly and is_out is
    replaced by usb_pipeout(pipe). The WARN_ON() calls become unnecessary
    and get removed.
    
    Finally, the return type is changed from __u16 to u16 because this is
    not a UAPI function.
    
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Link: https://lore.kernel.org/r/20220317035514.6378-2-mailhol.vincent@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 69aeb5073123 ("Input: pegasus-notetaker - fix potential out-of-bounds access")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb9734d8e92c6c5884e13c607cd04aade9f4a638
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Nov 24 22:27:07 2025 -0500

    mptcp: do not fallback when OoO is present
    
    [ Upstream commit 1bba3f219c5e8c29e63afa3c1fc24f875ebec119 ]
    
    In case of DSS corruption, the MPTCP protocol tries to avoid the subflow
    reset if fallback is possible. Such corruptions happen in the receive
    path; to ensure fallback is possible the stack additionally needs to
    check for OoO data, otherwise the fallback will break the data stream.
    
    Fixes: e32d262c89e2 ("mptcp: handle consistently DSS corruption")
    Cc: stable@vger.kernel.org
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/598
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-4-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ patch mptcp_dss_corruption() ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9be29f8e7ce4e147e56caac2c3a0ce3573cf9c17
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 24 21:58:41 2025 -0500

    mptcp: fix a race in mptcp_pm_del_add_timer()
    
    [ Upstream commit 426358d9be7ce3518966422f87b96f1bad27295f ]
    
    mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)
    while another might have free entry already, as reported by syzbot.
    
    Add RCU protection to fix this issue.
    
    Also change confusing add_timer variable with stop_timer boolean.
    
    syzbot report:
    
    BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616
    Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44
    
    CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
    Workqueue: events mptcp_worker
    Call Trace:
     <TASK>
      dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
      print_address_description mm/kasan/report.c:378 [inline]
      print_report+0xca/0x240 mm/kasan/report.c:482
      kasan_report+0x118/0x150 mm/kasan/report.c:595
      __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616
      sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631
      mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362
      mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174
      tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361
      tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441
      tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931
      tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374
      ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205
      ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239
      NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318
      NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318
      __netif_receive_skb_one_core net/core/dev.c:6079 [inline]
      __netif_receive_skb+0x143/0x380 net/core/dev.c:6192
      process_backlog+0x31e/0x900 net/core/dev.c:6544
      __napi_poll+0xb6/0x540 net/core/dev.c:7594
      napi_poll net/core/dev.c:7657 [inline]
      net_rx_action+0x5f7/0xda0 net/core/dev.c:7784
      handle_softirqs+0x22f/0x710 kernel/softirq.c:622
      __do_softirq kernel/softirq.c:656 [inline]
      __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302
      mptcp_pm_send_ack net/mptcp/pm.c:210 [inline]
     mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1
      mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002
      mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762
      process_one_work kernel/workqueue.c:3263 [inline]
      process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346
      worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427
      kthread+0x711/0x8a0 kernel/kthread.c:463
      ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
     </TASK>
    
    Allocated by task 44:
      kasan_save_stack mm/kasan/common.c:56 [inline]
      kasan_save_track+0x3e/0x80 mm/kasan/common.c:77
      poison_kmalloc_redzone mm/kasan/common.c:400 [inline]
      __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417
      kasan_kmalloc include/linux/kasan.h:262 [inline]
      __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748
      kmalloc_noprof include/linux/slab.h:957 [inline]
      mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385
      mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355
      mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline]
      __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529
      mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008
      mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762
      process_one_work kernel/workqueue.c:3263 [inline]
      process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346
      worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427
      kthread+0x711/0x8a0 kernel/kthread.c:463
      ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
    
    Freed by task 6630:
      kasan_save_stack mm/kasan/common.c:56 [inline]
      kasan_save_track+0x3e/0x80 mm/kasan/common.c:77
      __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587
      kasan_save_free_info mm/kasan/kasan.h:406 [inline]
      poison_slab_object mm/kasan/common.c:252 [inline]
      __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284
      kasan_slab_free include/linux/kasan.h:234 [inline]
      slab_free_hook mm/slub.c:2523 [inline]
      slab_free mm/slub.c:6611 [inline]
      kfree+0x197/0x950 mm/slub.c:6818
      mptcp_remove_anno_list_by_saddr+0x2d/0x40 net/mptcp/pm.c:158
      mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_kernel.c:1209 [inline]
      mptcp_nl_flush_addrs_list net/mptcp/pm_kernel.c:1240 [inline]
      mptcp_pm_nl_flush_addrs_doit+0x593/0xbb0 net/mptcp/pm_kernel.c:1281
      genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115
      genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
      genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210
      netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552
      genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
      netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
      netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346
      netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896
      sock_sendmsg_nosec net/socket.c:727 [inline]
      __sock_sendmsg+0x21c/0x270 net/socket.c:742
      ____sys_sendmsg+0x508/0x820 net/socket.c:2630
      ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2684
      __sys_sendmsg net/socket.c:2716 [inline]
      __do_sys_sendmsg net/socket.c:2721 [inline]
      __se_sys_sendmsg net/socket.c:2719 [inline]
      __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2719
      do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
      do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Cc: stable@vger.kernel.org
    Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout")
    Reported-by: syzbot+2a6fbf0f0530375968df@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/691ad3c3.a70a0220.f6df1.0004.GAE@google.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Geliang Tang <geliang@kernel.org>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20251117100745.1913963-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ applied changes to pm_netlink.c instead of pm.c ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c07e28a3bacc745cf65a0dcf7c44ebfaf83f57f2
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Nov 24 16:33:27 2025 -0500

    dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups
    
    [ Upstream commit 316e361b5d2cdeb8d778983794a1c6eadcb26814 ]
    
    The "groups" property can hold multiple entries (e.g.
    toshiba/tmpv7708-rm-mbrc.dts file), so allow that by dropping incorrect
    type (pinmux-node.yaml schema already defines that as string-array) and
    adding constraints for items.  This fixes dtbs_check warnings like:
    
      toshiba/tmpv7708-rm-mbrc.dtb: pinctrl@24190000 (toshiba,tmpv7708-pinctrl):
        pwm-pins:groups: ['pwm0_gpio16_grp', 'pwm1_gpio17_grp', 'pwm2_gpio18_grp', 'pwm3_gpio19_grp'] is too long
    
    Fixes: 1825c1fe0057 ("pinctrl: Add DT bindings for Toshiba Visconti TMPV7700 SoC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    [ adjusted $ref context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f865e6595acf33083168db76921e66ace8bf0e5b
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 24 15:59:17 2025 -0500

    mptcp: fix race condition in mptcp_schedule_work()
    
    [ Upstream commit 035bca3f017ee9dea3a5a756e77a6f7138cc6eea ]
    
    syzbot reported use-after-free in mptcp_schedule_work() [1]
    
    Issue here is that mptcp_schedule_work() schedules a work,
    then gets a refcount on sk->sk_refcnt if the work was scheduled.
    This refcount will be released by mptcp_worker().
    
    [A] if (schedule_work(...)) {
    [B]     sock_hold(sk);
            return true;
        }
    
    Problem is that mptcp_worker() can run immediately and complete before [B]
    
    We need instead :
    
        sock_hold(sk);
        if (schedule_work(...))
            return true;
        sock_put(sk);
    
    [1]
    refcount_t: addition on 0; use-after-free.
     WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25
    Call Trace:
     <TASK>
     __refcount_add include/linux/refcount.h:-1 [inline]
      __refcount_inc include/linux/refcount.h:366 [inline]
      refcount_inc include/linux/refcount.h:383 [inline]
      sock_hold include/net/sock.h:816 [inline]
      mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943
      mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316
      call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747
      expire_timers kernel/time/timer.c:1798 [inline]
      __run_timers kernel/time/timer.c:2372 [inline]
      __run_timer_base+0x648/0x970 kernel/time/timer.c:2384
      run_timer_base kernel/time/timer.c:2393 [inline]
      run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403
      handle_softirqs+0x22f/0x710 kernel/softirq.c:622
      __do_softirq kernel/softirq.c:656 [inline]
      run_ktimerd+0xcf/0x190 kernel/softirq.c:1138
      smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160
      kthread+0x711/0x8a0 kernel/kthread.c:463
      ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
    
    Cc: stable@vger.kernel.org
    Fixes: 3b1d6210a957 ("mptcp: implement and use MPTCP-level retransmission")
    Reported-by: syzbot+355158e7e301548a1424@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/6915b46f.050a0220.3565dc.0028.GAE@google.com/T/#u
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20251113103924.3737425-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b6aed3a9350744180a9e9bbb449b179cdab2cf9
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Nov 24 15:59:16 2025 -0500

    mptcp: introduce mptcp_schedule_work
    
    [ Upstream commit ba8f48f7a4d79352b764ace585b5f602ef940be0 ]
    
    remove some of code duplications an allow preventing
    rescheduling on close.
    
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 035bca3f017e ("mptcp: fix race condition in mptcp_schedule_work()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ab3b55df0c2068c63c5b28448aadd2df9a2307f
Author: Niklas Cassel <cassel@kernel.org>
Date:   Mon Nov 24 14:04:57 2025 -0500

    ata: libata-scsi: Fix system suspend for a security locked drive
    
    [ Upstream commit b11890683380a36b8488229f818d5e76e8204587 ]
    
    Commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status
    handling") fixed ata_to_sense_error() to properly generate sense key
    ABORTED COMMAND (without any additional sense code), instead of the
    previous bogus sense key ILLEGAL REQUEST with the additional sense code
    UNALIGNED WRITE COMMAND, for a failed command.
    
    However, this broke suspend for Security locked drives (drives that have
    Security enabled, and have not been Security unlocked by boot firmware).
    
    The reason for this is that the SCSI disk driver, for the Synchronize
    Cache command only, treats any sense data with sense key ILLEGAL REQUEST
    as a successful command (regardless of ASC / ASCQ).
    
    After commit cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error()
    status handling") the code that treats any sense data with sense key
    ILLEGAL REQUEST as a successful command is no longer applicable, so the
    command fails, which causes the system suspend to be aborted:
    
      sd 1:0:0:0: PM: dpm_run_callback(): scsi_bus_suspend returns -5
      sd 1:0:0:0: PM: failed to suspend async: error -5
      PM: Some devices failed to suspend, or early wake event detected
    
    To make suspend work once again, for a Security locked device only,
    return sense data LOGICAL UNIT ACCESS NOT AUTHORIZED, the actual sense
    data which a real SCSI device would have returned if locked.
    The SCSI disk driver treats this sense data as a successful command.
    
    Cc: stable@vger.kernel.org
    Reported-by: Ilia Baryshnikov <qwelias@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220704
    Fixes: cf3fc037623c ("ata: libata-scsi: Fix ata_to_sense_error() status handling")
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6e11d320fd6cbaef6d589f2fcb45aa25a6b960a
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Fri Nov 21 11:57:51 2025 -0500

    pmdomain: arm: scmi: Fix genpd leak on provider registration failure
    
    [ Upstream commit 7458f72cc28f9eb0de811effcb5376d0ec19094a ]
    
    If of_genpd_add_provider_onecell() fails during probe, the previously
    created generic power domains are not removed, leading to a memory leak
    and potential kernel crash later in genpd_debug_add().
    
    Add proper error handling to unwind the initialized domains before
    returning from probe to ensure all resources are correctly released on
    failure.
    
    Example crash trace observed without this fix:
    
      | Unable to handle kernel paging request at virtual address fffffffffffffc70
      | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT
      | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform
      | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      | pc : genpd_debug_add+0x2c/0x160
      | lr : genpd_debug_init+0x74/0x98
      | Call trace:
      |  genpd_debug_add+0x2c/0x160 (P)
      |  genpd_debug_init+0x74/0x98
      |  do_one_initcall+0xd0/0x2d8
      |  do_initcall_level+0xa0/0x140
      |  do_initcalls+0x60/0xa8
      |  do_basic_setup+0x28/0x40
      |  kernel_init_freeable+0xe8/0x170
      |  kernel_init+0x2c/0x140
      |  ret_from_fork+0x10/0x20
    
    Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd")
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    [ drivers/pmdomain/arm/scmi_pm_domain.c -> drivers/firmware/arm_scmi/scmi_pm_domain.c ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f579f0e0d42a2e811d08610d821179c7157eaef7
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Nov 21 11:57:48 2025 -0500

    pmdomain: imx: Fix reference count leak in imx_gpc_remove
    
    [ Upstream commit bbde14682eba21d86f5f3d6fe2d371b1f97f1e61 ]
    
    of_get_child_by_name() returns a node pointer with refcount incremented, we
    should use of_node_put() on it when not needed anymore. Add the missing
    of_node_put() to avoid refcount leak.
    
    Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    [ drivers/pmdomain/imx/gpc.c -> drivers/soc/imx/gpc.c ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a5da3fa80affc948923f20a4e086177f505e86e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Nov 21 10:12:56 2025 -0500

    ALSA: usb-audio: Fix potential overflow of PCM transfer buffer
    
    [ Upstream commit 05a1fc5efdd8560f34a3af39c9cf1e1526cc3ddf ]
    
    The PCM stream data in USB-audio driver is transferred over USB URB
    packet buffers, and each packet size is determined dynamically.  The
    packet sizes are limited by some factors such as wMaxPacketSize USB
    descriptor.  OTOH, in the current code, the actually used packet sizes
    are determined only by the rate and the PPS, which may be bigger than
    the size limit above.  This results in a buffer overflow, as reported
    by syzbot.
    
    Basically when the limit is smaller than the calculated packet size,
    it implies that something is wrong, most likely a weird USB
    descriptor.  So the best option would be just to return an error at
    the parameter setup time before doing any further operations.
    
    This patch introduces such a sanity check, and returns -EINVAL when
    the packet size is greater than maxpacksize.  The comparison with
    ep->packsize[1] alone should suffice since it's always equal or
    greater than ep->packsize[0].
    
    Reported-by: syzbot+bfd77469c8966de076f7@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=bfd77469c8966de076f7
    Link: https://lore.kernel.org/690b6b46.050a0220.3d0d33.0054.GAE@google.com
    Cc: Lizhi Xu <lizhi.xu@windriver.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20251109091211.12739-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [ changed ep->cur_rate to rate parameter and chip to ep->chip ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b0bb18b4b9dc017c1825a2c5e763615e34a1593
Author: Breno Leitao <leitao@debian.org>
Date:   Thu Nov 20 20:59:38 2025 -0500

    net: netpoll: fix incorrect refcount handling causing incorrect cleanup
    
    [ Upstream commit 49c8d2c1f94cc2f4d1a108530d7ba52614b874c2 ]
    
    commit efa95b01da18 ("netpoll: fix use after free") incorrectly
    ignored the refcount and prematurely set dev->npinfo to NULL during
    netpoll cleanup, leading to improper behavior and memory leaks.
    
    Scenario causing lack of proper cleanup:
    
    1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is
       allocated, and refcnt = 1
       - Keep in mind that npinfo is shared among all netpoll instances. In
         this case, there is just one.
    
    2) Another netpoll is also associated with the same NIC and
       npinfo->refcnt += 1.
       - Now dev->npinfo->refcnt = 2;
       - There is just one npinfo associated to the netdev.
    
    3) When the first netpolls goes to clean up:
       - The first cleanup succeeds and clears np->dev->npinfo, ignoring
         refcnt.
         - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);`
       - Set dev->npinfo = NULL, without proper cleanup
       - No ->ndo_netpoll_cleanup() is either called
    
    4) Now the second target tries to clean up
       - The second cleanup fails because np->dev->npinfo is already NULL.
         * In this case, ops->ndo_netpoll_cleanup() was never called, and
           the skb pool is not cleaned as well (for the second netpoll
           instance)
      - This leaks npinfo and skbpool skbs, which is clearly reported by
        kmemleak.
    
    Revert commit efa95b01da18 ("netpoll: fix use after free") and adds
    clarifying comments emphasizing that npinfo cleanup should only happen
    once the refcount reaches zero, ensuring stable and correct netpoll
    behavior.
    
    Cc: <stable@vger.kernel.org> # 3.17.x
    Cc: Jay Vosburgh <jv@jvosburgh.net>
    Fixes: efa95b01da18 ("netpoll: fix use after free")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20251107-netconsole_torture-v10-1-749227b55f63@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0ba16ba08bab3fa11d309717c8e877fd68b7529
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat Nov 22 10:28:09 2025 -0500

    Revert "NFS: Don't set NFS_INO_REVAL_PAGECACHE in the inode cache validity"
    
    This reverts commit 36a9346c225270262d9f34e66c91aa1723fa903f.
    
    The above commit was incorrectly labelled as a dependency for commit
    b01f21cacde9 ("NFS: Fix the setting of capabilities when automounting a
    new filesystem")
    A revert is needed, since the incorrectly applied commit depends upon a
    series of other patches that were merged into Linux 5.13, but have not
    been applied to the 5.10 stable series.
    
    Reported-by: "Ahmed, Aaron" <aarnahmd@amazon.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb976b658da9cfb23fd6a9395b390cba5ed3278b
Author: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Date:   Mon Sep 19 10:08:28 2022 -0700

    Makefile.compiler: replace cc-ifversion with compiler-specific macros
    
    commit 88b61e3bff93f99712718db785b4aa0c1165f35c upstream.
    
    cc-ifversion is GCC specific. Replace it with compiler specific
    variants. Update the users of cc-ifversion to use these new macros.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/350
    Link: https://lore.kernel.org/llvm/CAGG=3QWSAUakO42kubrCap8fp-gm1ERJJAYXTnP1iHk_wrH=BQ@mail.gmail.com/
    Suggested-by: Bill Wendling <morbo@google.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    [nathan: Backport to 5.10 and eliminate instances of cc-ifversion that
             did not exist upstream when this change was original created]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99e0c016b59e2267583553d1363b75537b1e516f
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed May 7 21:47:45 2025 +0100

    net: qede: Initialize qede_ll_ops with designated initializer
    
    commit 6b3ab7f2cbfaeb6580709cd8ef4d72cfd01bfde4 upstream.
    
    After a recent change [1] in clang's randstruct implementation to
    randomize structures that only contain function pointers, there is an
    error because qede_ll_ops get randomized but does not use a designated
    initializer for the first member:
    
      drivers/net/ethernet/qlogic/qede/qede_main.c:206:2: error: a randomized struct can only be initialized with a designated initializer
        206 |         {
            |         ^
    
    Explicitly initialize the common member using a designated initializer
    to fix the build.
    
    Cc: stable@vger.kernel.org
    Fixes: 035f7f87b729 ("randstruct: Enable Clang support")
    Link: https://github.com/llvm/llvm-project/commit/04364fb888eea6db9811510607bed4b200bcb082 [1]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://patch.msgid.link/20250507-qede-fix-clang-randstruct-v1-1-5ccc15626fba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d01fb18bdfa39c1293fe687aa33ae9e37bd03d74
Author: Long Li <longli@microsoft.com>
Date:   Mon Mar 10 15:12:01 2025 -0700

    uio_hv_generic: Set event for all channels on the device
    
    commit d062463edf1770427dc2d637df4088df4835aa47 upstream.
    
    Hyper-V may offer a non latency sensitive device with subchannels without
    monitor bit enabled. The decision is entirely on the Hyper-V host not
    configurable within guest.
    
    When a device has subchannels, also signal events for the subchannel
    if its monitor bit is disabled.
    
    This patch also removes the memory barrier when monitor bit is enabled
    as it is not necessary. The memory barrier is only needed between
    setting up interrupt mask and calling vmbus_set_event() when monitor
    bit is disabled.
    
    Signed-off-by: Long Li <longli@microsoft.com>
    Reviewed-by: Michael Kelley <mhklinux@outlook.com>
    Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Link: https://lore.kernel.org/r/1741644721-20389-1-git-send-email-longli@linuxonhyperv.com
    Fixes: b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt mask")
    Closes: https://bugs.debian.org/1120602
    Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8427218ecbd7f8559c37972e66cb0fa06e82353b
Author: Nishanth Menon <nm@ti.com>
Date:   Mon Nov 3 10:28:11 2025 -0600

    net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error
    
    [ Upstream commit 90a88306eb874fe4bbdd860e6c9787f5bbc588b5 ]
    
    Make knav_dma_open_channel consistently return NULL on error instead
    of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h
    returns NULL when the driver is disabled, but the driver
    implementation does not even return NULL or ERR_PTR on failure,
    causing inconsistency in the users. This results in a crash in
    netcp_free_navigator_resources as followed (trimmed):
    
    Unhandled fault: alignment exception (0x221) at 0xfffffff2
    [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000
    Internal error: : 221 [#1] SMP ARM
    Modules linked in:
    CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE
    Hardware name: Keystone
    PC is at knav_dma_close_channel+0x30/0x19c
    LR is at netcp_free_navigator_resources+0x2c/0x28c
    
    [... TRIM...]
    
    Call trace:
     knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c
     netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c
     netcp_ndo_open from __dev_open+0x114/0x29c
     __dev_open from __dev_change_flags+0x190/0x208
     __dev_change_flags from netif_change_flags+0x1c/0x58
     netif_change_flags from dev_change_flags+0x38/0xa0
     dev_change_flags from ip_auto_config+0x2c4/0x11f0
     ip_auto_config from do_one_initcall+0x58/0x200
     do_one_initcall from kernel_init_freeable+0x1cc/0x238
     kernel_init_freeable from kernel_init+0x1c/0x12c
     kernel_init from ret_from_fork+0x14/0x38
    [... TRIM...]
    
    Standardize the error handling by making the function return NULL on
    all error conditions. The API is used in just the netcp_core.c so the
    impact is limited.
    
    Note, this change, in effect reverts commit 5b6cb43b4d62 ("net:
    ethernet: ti: netcp_core: return error while dma channel open issue"),
    but provides a less error prone implementation.
    
    Suggested-by: Simon Horman <horms@kernel.org>
    Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://patch.msgid.link/20251103162811.3730055-1-nm@ti.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de74f6c4e58e41b3b567f067d4249521f25d93c7
Author: René Rebe <rene@exactco.de>
Date:   Tue Nov 25 15:41:49 2025 +0100

    ALSA: usb-audio: fix uac2 clock source at terminal parser
    
    [ Upstream commit d26e9f669cc0a6a85cf17180c09a6686db9f4002 ]
    
    Since 8b3a087f7f65 ("ALSA: usb-audio: Unify virtual type units type to
    UAC3 values") usb-audio is using UAC3_CLOCK_SOURCE instead of
    bDescriptorSubtype, later refactored with e0ccdef9265 ("ALSA: usb-audio:
    Clean up check_input_term()") into parse_term_uac2_clock_source().
    
    This breaks the clock source selection for at least my
    1397:0003 BEHRINGER International GmbH FCA610 Pro.
    
    Fix by using UAC2_CLOCK_SOURCE in parse_term_uac2_clock_source().
    
    Fixes: 8b3a087f7f65 ("ALSA: usb-audio: Unify virtual type units type to UAC3 values")
    Signed-off-by: René Rebe <rene@exactco.de>
    Link: https://patch.msgid.link/20251125.154149.1121389544970412061.rene@exactco.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 567ff64193a18f8741c4d3fdc4caab098f4f6c62
Author: Isaac J. Manjarres <isaacmanjarres@google.com>
Date:   Thu Nov 20 21:40:41 2025 +0200

    mm/mm_init: fix hash table order logging in alloc_large_system_hash()
    
    [ Upstream commit 0d6c356dd6547adac2b06b461528e3573f52d953 ]
    
    When emitting the order of the allocation for a hash table,
    alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from log
    base 2 of the allocation size.  This is not correct if the allocation size
    is smaller than a page, and yields a negative value for the order as seen
    below:
    
    TCP established hash table entries: 32 (order: -4, 256 bytes, linear) TCP
    bind hash table entries: 32 (order: -2, 1024 bytes, linear)
    
    Use get_order() to compute the order when emitting the hash table
    information to correctly handle cases where the allocation size is smaller
    than a page:
    
    TCP established hash table entries: 32 (order: 0, 256 bytes, linear) TCP
    bind hash table entries: 32 (order: 0, 1024 bytes, linear)
    
    Link: https://lkml.kernel.org/r/20251028191020.413002-1-isaacmanjarres@google.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
    Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    (cherry picked from commit 0d6c356dd6547adac2b06b461528e3573f52d953)
    Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9898aa3f865fb44b1ed18612aad4402547452557
Author: Jakub Horký <jakub.git@horky.net>
Date:   Tue Oct 14 16:44:06 2025 +0200

    kconfig/nconf: Initialize the default locale at startup
    
    [ Upstream commit 43c2931a95e6b295bfe9e3b90dbe0f7596933e91 ]
    
    Fix bug where make nconfig doesn't initialize the default locale, which
    causes ncurses menu borders to be displayed incorrectly (lqqqqk) in
    UTF-8 terminals that don't support VT100 ACS by default, such as PuTTY.
    
    Signed-off-by: Jakub Horký <jakub.git@horky.net>
    Link: https://patch.msgid.link/20251014144405.3975275-2-jakub.git@horky.net
    [nathan: Alphabetize locale.h include]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af7ea2d9bc45c6ab7dad66fb9d11df9312b664f3
Author: Jakub Horký <jakub.git@horky.net>
Date:   Tue Oct 14 17:49:32 2025 +0200

    kconfig/mconf: Initialize the default locale at startup
    
    [ Upstream commit 3927c4a1084c48ef97f11281a0a43ecb2cb4d6f1 ]
    
    Fix bug where make menuconfig doesn't initialize the default locale, which
    causes ncurses menu borders to be displayed incorrectly (lqqqqk) in
    UTF-8 terminals that don't support VT100 ACS by default, such as PuTTY.
    
    Signed-off-by: Jakub Horký <jakub.git@horky.net>
    Link: https://patch.msgid.link/20251014154933.3990990-1-jakub.git@horky.net
    [nathan: Alphabetize locale.h include]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a17685c4766cdc9babb3b7ab7b8822eb5a79025
Author: Shahar Shitrit <shshitrit@nvidia.com>
Date:   Sun Oct 26 22:03:02 2025 +0200

    net: tls: Cancel RX async resync request on rcd_delta overflow
    
    [ Upstream commit c15d5c62ab313c19121f10e25d4fec852bd1c40c ]
    
    When a netdev issues a RX async resync request for a TLS connection,
    the TLS module handles it by logging record headers and attempting to
    match them to the tcp_sn provided by the device. If a match is found,
    the TLS module approves the tcp_sn for resynchronization.
    
    While waiting for a device response, the TLS module also increments
    rcd_delta each time a new TLS record is received, tracking the distance
    from the original resync request.
    
    However, if the device response is delayed or fails (e.g due to
    unstable connection and device getting out of tracking, hardware
    errors, resource exhaustion etc.), the TLS module keeps logging and
    incrementing, which can lead to a WARN() when rcd_delta exceeds the
    threshold.
    
    To address this, introduce tls_offload_rx_resync_async_request_cancel()
    to explicitly cancel resync requests when a device response failure is
    detected. Call this helper also as a final safeguard when rcd_delta
    crosses its threshold, as reaching this point implies that earlier
    cancellation did not occur.
    
    Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://patch.msgid.link/1761508983-937977-3-git-send-email-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 143257917b836bd5fc434063030fda199e249624
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Oct 7 14:48:00 2025 -0700

    scsi: core: Fix a regression triggered by scsi_host_busy()
    
    [ Upstream commit a0b7780602b1b196f47e527fec82166a7e67c4d0 ]
    
    Commit 995412e23bb2 ("blk-mq: Replace tags->lock with SRCU for tag
    iterators") introduced the following regression:
    
    Call trace:
     __srcu_read_lock+0x30/0x80 (P)
     blk_mq_tagset_busy_iter+0x44/0x300
     scsi_host_busy+0x38/0x70
     ufshcd_print_host_state+0x34/0x1bc
     ufshcd_link_startup.constprop.0+0xe4/0x2e0
     ufshcd_init+0x944/0xf80
     ufshcd_pltfrm_init+0x504/0x820
     ufs_rockchip_probe+0x2c/0x88
     platform_probe+0x5c/0xa4
     really_probe+0xc0/0x38c
     __driver_probe_device+0x7c/0x150
     driver_probe_device+0x40/0x120
     __driver_attach+0xc8/0x1e0
     bus_for_each_dev+0x7c/0xdc
     driver_attach+0x24/0x30
     bus_add_driver+0x110/0x230
     driver_register+0x68/0x130
     __platform_driver_register+0x20/0x2c
     ufs_rockchip_pltform_init+0x1c/0x28
     do_one_initcall+0x60/0x1e0
     kernel_init_freeable+0x248/0x2c4
     kernel_init+0x20/0x140
     ret_from_fork+0x10/0x20
    
    Fix this regression by making scsi_host_busy() check whether the SCSI
    host tag set has already been initialized. tag_set->ops is set by
    scsi_mq_setup_tags() just before blk_mq_alloc_tag_set() is called. This
    fix is based on the assumption that scsi_host_busy() and
    scsi_mq_setup_tags() calls are serialized. This is the case in the UFS
    driver.
    
    Reported-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Closes: https://lore.kernel.org/linux-block/pnezafputodmqlpumwfbn644ohjybouveehcjhz2hmhtcf2rka@sdhoiivync4y/
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Link: https://patch.msgid.link/20251007214800.1678255-1-bvanassche@acm.org
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da664101fb4a0de5cb70d2bae6a650df954df2af
Author: Michal Luczaj <mhal@rbox.co>
Date:   Wed Nov 19 15:02:59 2025 +0100

    vsock: Ignore signal/timeout on connect() if already established
    
    [ Upstream commit 002541ef650b742a198e4be363881439bb9d86b4 ]
    
    During connect(), acting on a signal/timeout by disconnecting an already
    established socket leads to several issues:
    
    1. connect() invoking vsock_transport_cancel_pkt() ->
       virtio_transport_purge_skbs() may race with sendmsg() invoking
       virtio_transport_get_credit(). This results in a permanently elevated
       `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.
    
    2. connect() resetting a connected socket's state may race with socket
       being placed in a sockmap. A disconnected socket remaining in a sockmap
       breaks sockmap's assumptions. And gives rise to WARNs.
    
    3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a
       transport change/drop after TCP_ESTABLISHED. Which poses a problem for
       any simultaneous sendmsg() or connect() and may result in a
       use-after-free/null-ptr-deref.
    
    Do not disconnect socket on signal/timeout. Keep the logic for unconnected
    sockets: they don't linger, can't be placed in a sockmap, are rejected by
    sendmsg().
    
    [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/
    [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/
    [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Signed-off-by: Michal Luczaj <mhal@rbox.co>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://patch.msgid.link/20251119-vsock-interrupted-connect-v2-1-70734cf1233f@rbox.co
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bf8ccaabce8cebb6cb1f255c93d0acdfe95c17a
Author: Aleksei Nikiforov <aleksei.nikiforov@linux.ibm.com>
Date:   Wed Nov 12 19:27:24 2025 +0100

    s390/ctcm: Fix double-kfree
    
    [ Upstream commit da02a1824884d6c84c5e5b5ac373b0c9e3288ec2 ]
    
    The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally
    from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.
    After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'
    frees it again.
    
    Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.
    
    Bug detected by the clang static analyzer.
    
    Fixes: 0c0b20587b9f25a2 ("s390/ctcm: fix potential memory leak")
    Reviewed-by: Aswin Karuvally <aswin@linux.ibm.com>
    Signed-off-by: Aleksei Nikiforov <aleksei.nikiforov@linux.ibm.com>
    Signed-off-by: Aswin Karuvally <aswin@linux.ibm.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20251112182724.1109474-1-aswin@linux.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d2e7d3b28469081ccf08301df07cc411a1cc5e9
Author: Ilya Maximets <i.maximets@ovn.org>
Date:   Wed Nov 12 12:14:03 2025 +0100

    net: openvswitch: remove never-working support for setting nsh fields
    
    [ Upstream commit dfe28c4167a9259fc0c372d9f9473e1ac95cff67 ]
    
    The validation of the set(nsh(...)) action is completely wrong.
    It runs through the nsh_key_put_from_nlattr() function that is the
    same function that validates NSH keys for the flow match and the
    push_nsh() action.  However, the set(nsh(...)) has a very different
    memory layout.  Nested attributes in there are doubled in size in
    case of the masked set().  That makes proper validation impossible.
    
    There is also confusion in the code between the 'masked' flag, that
    says that the nested attributes are doubled in size containing both
    the value and the mask, and the 'is_mask' that says that the value
    we're parsing is the mask.  This is causing kernel crash on trying to
    write into mask part of the match with SW_FLOW_KEY_PUT() during
    validation, while validate_nsh() doesn't allocate any memory for it:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000018
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0
      Oops: Oops: 0000 [#1] SMP NOPTI
      CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary)
      RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch]
      Call Trace:
       <TASK>
       validate_nsh+0x60/0x90 [openvswitch]
       validate_set.constprop.0+0x270/0x3c0 [openvswitch]
       __ovs_nla_copy_actions+0x477/0x860 [openvswitch]
       ovs_nla_copy_actions+0x8d/0x100 [openvswitch]
       ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch]
       genl_family_rcv_msg_doit+0xdb/0x130
       genl_family_rcv_msg+0x14b/0x220
       genl_rcv_msg+0x47/0xa0
       netlink_rcv_skb+0x53/0x100
       genl_rcv+0x24/0x40
       netlink_unicast+0x280/0x3b0
       netlink_sendmsg+0x1f7/0x430
       ____sys_sendmsg+0x36b/0x3a0
       ___sys_sendmsg+0x87/0xd0
       __sys_sendmsg+0x6d/0xd0
       do_syscall_64+0x7b/0x2c0
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    The third issue with this process is that while trying to convert
    the non-masked set into masked one, validate_set() copies and doubles
    the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested
    attributes.  It should be copying each nested attribute and doubling
    them in size independently.  And the process must be properly reversed
    during the conversion back from masked to a non-masked variant during
    the flow dump.
    
    In the end, the only two outcomes of trying to use this action are
    either validation failure or a kernel crash.  And if somehow someone
    manages to install a flow with such an action, it will most definitely
    not do what it is supposed to, since all the keys and the masks are
    mixed up.
    
    Fixing all the issues is a complex task as it requires re-writing
    most of the validation code.
    
    Given that and the fact that this functionality never worked since
    introduction, let's just remove it altogether.  It's better to
    re-introduce it later with a proper implementation instead of trying
    to fix it in stable releases.
    
    Fixes: b2d0f5d5dc53 ("openvswitch: enable NSH support")
    Reported-by: Junvy Yang <zhuque@tencent.com>
    Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
    Acked-by: Eelco Chaudron <echaudro@redhat.com>
    Reviewed-by: Aaron Conole <aconole@redhat.com>
    Link: https://patch.msgid.link/20251112112246.95064-1-i.maximets@ovn.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d479a474993f4cf7a415380cde345b18c33a968a
Author: Zilin Guan <zilin@seu.edu.cn>
Date:   Wed Nov 12 05:21:14 2025 +0000

    mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()
    
    [ Upstream commit 407a06507c2358554958e8164dc97176feddcafc ]
    
    The function mlxsw_sp_flower_stats() calls mlxsw_sp_acl_ruleset_get() to
    obtain a ruleset reference. If the subsequent call to
    mlxsw_sp_acl_rule_lookup() fails to find a rule, the function returns
    an error without releasing the ruleset reference, causing a memory leak.
    
    Fix this by using a goto to the existing error handling label, which
    calls mlxsw_sp_acl_ruleset_put() to properly release the reference.
    
    Fixes: 7c1b8eb175b69 ("mlxsw: spectrum: Add support for TC flower offload statistics")
    Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://patch.msgid.link/20251112052114.1591695-1-zilin@seu.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 693e99693e681c98b582399c4d21338052b98cd2
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Wed Oct 22 19:47:20 2025 +0800

    drm/tegra: dc: Fix reference leak in tegra_dc_couple()
    
    commit 4c5376b4b143c4834ebd392aef2215847752b16a upstream.
    
    driver_find_device() calls get_device() to increment the reference
    count once a matching device is found, but there is no put_device() to
    balance the reference count. To avoid reference count leakage, add
    put_device() to decrease the reference count.
    
    Found by code review.
    
    Cc: stable@vger.kernel.org
    Fixes: a31500fe7055 ("drm/tegra: dc: Restore coupling of display controllers")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Acked-by: Mikko Perttunen <mperttunen@nvidia.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://patch.msgid.link/20251022114720.24937-1-make24@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95a2076d39e6bc54afbecb4e8280b18ce3670491
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Mon Oct 20 02:11:49 2025 +0100

    MIPS: Malta: Fix !EVA SOC-it PCI MMIO
    
    commit ebd729fef31620e0bf74cbf8a4c7fda73a2a4e7e upstream.
    
    Fix a regression that has caused accesses to the PCI MMIO window to
    complete unclaimed in non-EVA configurations with the SOC-it family of
    system controllers, preventing PCI devices from working that use MMIO.
    
    In the non-EVA case PHYS_OFFSET is set to 0, meaning that PCI_BAR0 is
    set with an empty mask (and PCI_HEAD4 matches addresses starting from 0
    accordingly).  Consequently all addresses are matched for incoming DMA
    accesses from PCI.  This seems to confuse the system controller's logic
    and outgoing bus cycles targeting the PCI MMIO window seem not to make
    it to the intended devices.
    
    This happens as well when a wider mask is used with PCI_BAR0, such as
    0x80000000 or 0xe0000000, that makes addresses match that overlap with
    the PCI MMIO window, which starts at 0x10000000 in our configuration.
    
    Set the mask in PCI_BAR0 to 0xf0000000 for non-EVA then, covering the
    non-EVA maximum 256 MiB of RAM, which is what YAMON does and which used
    to work correctly up to the offending commit.  Set PCI_P2SCMSKL to match
    PCI_BAR0 as required by the system controller's specification, and match
    PCI_P2SCMAPL to PCI_HEAD4 for identity mapping.
    
    Verified with:
    
    Core board type/revision =      0x0d (Core74K) / 0x01
    System controller/revision =    MIPS SOC-it 101 OCP / 1.3   SDR-FW-4:1
    Processor Company ID/options =  0x01 (MIPS Technologies, Inc.) / 0x1c
    Processor ID/revision =         0x97 (MIPS 74Kf) / 0x4c
    
    for non-EVA and with:
    
    Core board type/revision =      0x0c (CoreFPGA-5) / 0x00
    System controller/revision =    MIPS ROC-it2 / 0.0   FW-1:1 (CLK_unknown) GIC
    Processor Company ID/options =  0x01 (MIPS Technologies, Inc.) / 0x00
    Processor ID/revision =         0xa0 (MIPS interAptiv UP) / 0x20
    
    for EVA/non-EVA, fixing:
    
    defxx 0000:00:12.0: assign IRQ: got 10
    defxx: v1.12 2021/03/10  Lawrence V. Stefani and others
    0000:00:12.0: Could not read adapter factory MAC address!
    
    vs:
    
    defxx 0000:00:12.0: assign IRQ: got 10
    defxx: v1.12 2021/03/10  Lawrence V. Stefani and others
    0000:00:12.0: DEFPA at MMIO addr = 0x10142000, IRQ = 10, Hardware addr = 00-00-f8-xx-xx-xx
    0000:00:12.0: registered as fddi0
    
    for non-EVA and causing no change for EVA.
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Fixes: 422dd256642b ("MIPS: Malta: Allow PCI devices DMA to lower 2GB physical")
    Cc: stable@vger.kernel.org # v4.9+
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d8c517f6eb27e47b1a198e05f8023038329b40b
Author: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
Date:   Wed Nov 5 11:25:46 2025 -0800

    scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
    
    commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc upstream.
    
    If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we
    attempt to dereference it in tcm_loop_tpg_address_show() we will get a
    segfault, see below for an example. So, check tl_hba->sh before
    dereferencing it.
    
      Unable to allocate struct scsi_host
      BUG: kernel NULL pointer dereference, address: 0000000000000194
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 0 P4D 0
      Oops: 0000 [#1] PREEMPT SMP NOPTI
      CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1
      Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024
      RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]
    ...
      Call Trace:
       <TASK>
       configfs_read_iter+0x12d/0x1d0 [configfs]
       vfs_read+0x1b5/0x300
       ksys_read+0x6f/0xf0
    ...
    
    Cc: stable@vger.kernel.org
    Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs")
    Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Reviewed-by: Allen Pais <apais@linux.microsoft.com>
    Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linux.microsoft.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db6ac8703ab2b473e1ec845f57f6dd961a388d9f
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Nov 13 10:16:43 2025 -0800

    scsi: sg: Do not sleep in atomic context
    
    commit 90449f2d1e1f020835cba5417234636937dd657e upstream.
    
    sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may
    sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead
    of disabled.
    
    Reported-by: syzbot+c01f8e6e73f20459912e@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-scsi/691560c4.a70a0220.3124cb.001a.GAE@google.com/
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: stable@vger.kernel.org
    Fixes: 97d27b0dd015 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://patch.msgid.link/20251113181643.1108973-1-bvanassche@acm.org
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d78e8e01251da032a5f7cbc9728e4ab1a5a5464
Author: Ewan D. Milne <emilne@redhat.com>
Date:   Mon Nov 10 16:20:01 2025 -0500

    nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()
    
    commit 0a2c5495b6d1ecb0fa18ef6631450f391a888256 upstream.
    
    nvme_fc_delete_assocation() waits for pending I/O to complete before
    returning, and an error can cause ->ioerr_work to be queued after
    cancel_work_sync() had been called.  Move the call to cancel_work_sync() to
    be after nvme_fc_delete_association() to ensure ->ioerr_work is not running
    when the nvme_fc_ctrl object is freed.  Otherwise the following can occur:
    
    [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL
    [ 1135.917705] ------------[ cut here ]------------
    [ 1135.922336] kernel BUG at lib/list_debug.c:52!
    [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI
    [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)
    [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025
    [ 1135.950969] Workqueue:  0x0 (nvme-wq)
    [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f
    [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b
    [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046
    [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000
    [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0
    [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08
    [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100
    [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0
    [ 1136.020677] FS:  0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000
    [ 1136.028765] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0
    [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
    [ 1136.055910] PKRU: 55555554
    [ 1136.058623] Call Trace:
    [ 1136.061074]  <TASK>
    [ 1136.063179]  ? show_trace_log_lvl+0x1b0/0x2f0
    [ 1136.067540]  ? show_trace_log_lvl+0x1b0/0x2f0
    [ 1136.071898]  ? move_linked_works+0x4a/0xa0
    [ 1136.075998]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f
    [ 1136.081744]  ? __die_body.cold+0x8/0x12
    [ 1136.085584]  ? die+0x2e/0x50
    [ 1136.088469]  ? do_trap+0xca/0x110
    [ 1136.091789]  ? do_error_trap+0x65/0x80
    [ 1136.095543]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f
    [ 1136.101289]  ? exc_invalid_op+0x50/0x70
    [ 1136.105127]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f
    [ 1136.110874]  ? asm_exc_invalid_op+0x1a/0x20
    [ 1136.115059]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f
    [ 1136.120806]  move_linked_works+0x4a/0xa0
    [ 1136.124733]  worker_thread+0x216/0x3a0
    [ 1136.128485]  ? __pfx_worker_thread+0x10/0x10
    [ 1136.132758]  kthread+0xfa/0x240
    [ 1136.135904]  ? __pfx_kthread+0x10/0x10
    [ 1136.139657]  ret_from_fork+0x31/0x50
    [ 1136.143236]  ? __pfx_kthread+0x10/0x10
    [ 1136.146988]  ret_from_fork_asm+0x1a/0x30
    [ 1136.150915]  </TASK>
    
    Fixes: 19fce0470f05 ("nvme-fc: avoid calling _nvme_fc_abort_outstanding_ios from interrupt context")
    Cc: stable@vger.kernel.org
    Tested-by: Marco Patalano <mpatalan@redhat.com>
    Reviewed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e96803b169dc948847f0fc2bae729a80914eb7b
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat Nov 1 16:25:27 2025 +0300

    Input: imx_sc_key - fix memory corruption on unload
    
    commit d83f1512758f4ef6fc5e83219fe7eeeb6b428ea4 upstream.
    
    This is supposed to be "priv" but we accidentally pass "&priv" which is
    an address in the stack and so it will lead to memory corruption when
    the imx_sc_key_action() function is called.  Remove the &.
    
    Fixes: 768062fd1284 ("Input: imx_sc_key - use devm_add_action_or_reset() to handle all cleanups")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Link: https://patch.msgid.link/aQYKR75r2VMFJutT@stanley.mountain
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b5ae1521660c16fa830ff17d16e650b4905b71a
Author: Tzung-Bi Shih <tzungbi@kernel.org>
Date:   Tue Nov 4 07:03:10 2025 +0000

    Input: cros_ec_keyb - fix an invalid memory access
    
    commit e08969c4d65ac31297fcb4d31d4808c789152f68 upstream.
    
    If cros_ec_keyb_register_matrix() isn't called (due to
    `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains
    NULL.  An invalid memory access is observed in cros_ec_keyb_process()
    when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work()
    in such case.
    
      Unable to handle kernel read from unreadable memory at virtual address 0000000000000028
      ...
      x3 : 0000000000000000 x2 : 0000000000000000
      x1 : 0000000000000000 x0 : 0000000000000000
      Call trace:
      input_event
      cros_ec_keyb_work
      blocking_notifier_call_chain
      ec_irq_thread
    
    It's still unknown about why the kernel receives such malformed event,
    in any cases, the kernel shouldn't access `ckdev->idev` and friends if
    the driver doesn't intend to initialize them.
    
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Link: https://patch.msgid.link/20251104070310.3212712-1-tzungbi@kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f499dfa5c98e92e72dd454eb95a1000a448f3405
Author: Andrey Vatoropin <a.vatoropin@crpt.ru>
Date:   Wed Nov 19 10:51:12 2025 +0000

    be2net: pass wrb_params in case of OS2BMC
    
    commit 7d277a7a58578dd62fd546ddaef459ec24ccae36 upstream.
    
    be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL
    at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL
    pointer when processing a workaround for specific packet, as commit
    bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6
    packet") states.
    
    The correct way would be to pass the wrb_params from be_xmit().
    
    Fixes: 760c295e0e8d ("be2net: Support for OS2BMC.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andrey Vatoropin <a.vatoropin@crpt.ru>
    Link: https://patch.msgid.link/20251119105015.194501-1-a.vatoropin@crpt.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2644c38ef290d0dc96417ccc052be6f19b816f20
Author: Yongpeng Yang <yangyongpeng@xiaomi.com>
Date:   Tue Nov 4 20:50:07 2025 +0800

    exfat: check return value of sb_min_blocksize in exfat_read_boot_sector
    
    commit f2c1f631630e01821fe4c3fdf6077bc7a8284f82 upstream.
    
    sb_min_blocksize() may return 0. Check its return value to avoid
    accessing the filesystem super block when sb->s_blocksize is 0.
    
    Cc: stable@vger.kernel.org # v6.15
    Fixes: 719c1e1829166d ("exfat: add super block operations")
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
    Link: https://patch.msgid.link/20251104125009.2111925-3-yangyongpeng.storage@gmail.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2178b0255eae108bb10e5e99658b28641bc06f43
Author: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
Date:   Thu Oct 23 11:32:01 2025 +0800

    mtd: rawnand: cadence: fix DMA device NULL pointer dereference
    
    commit 5c56bf214af85ca042bf97f8584aab2151035840 upstream.
    
    The DMA device pointer `dma_dev` was being dereferenced before ensuring
    that `cdns_ctrl->dmac` is properly initialized.
    
    Move the assignment of `dma_dev` after successfully acquiring the DMA
    channel to ensure the pointer is valid before use.
    
    Fixes: d76d22b5096c ("mtd: rawnand: cadence: use dma_map_resource for sdma address")
    Cc: stable@vger.kernel.org
    Signed-off-by: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a92e831772399a6ff23f81cbecf6100f8540cd9
Author: Zhang Heng <zhangheng@kylinos.cn>
Date:   Fri Sep 12 20:38:18 2025 +0800

    HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155
    
    commit beab067dbcff642243291fd528355d64c41dc3b2 upstream.
    
    Based on available evidence, the USB ID 4c4a:4155 used by multiple
    devices has been attributed to Jieli. The commit 1a8953f4f774
    ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") affected touchscreen
    functionality. Added checks for manufacturer and serial number to
    maintain microphone compatibility, enabling both devices to function
    properly.
    
    [jkosina@suse.com: edit shortlog]
    Fixes: 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY")
    Cc: stable@vger.kernel.org
    Tested-by: staffan.melin@oscillator.se
    Reviewed-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
    Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adb7577e23a431fc53aa1b6107733c0d751015fb
Author: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Date:   Thu Oct 30 09:55:22 2025 +0530

    isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()
    
    commit 3f978e3f1570155a1327ffa25f60968bc7b9398f upstream.
    
    In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when
    setup_instance() fails with an error code. Fix that by freeing the urb
    before freeing the hw structure. Also change the error paths to use the
    goto ladder style.
    
    Compile tested only. Issue found using a prototype static analysis tool.
    
    Fixes: 69f52adb2d53 ("mISDN: Add HFC USB driver")
    Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
    Link: https://patch.msgid.link/20251030042524.194812-1-nihaal@cse.iitm.ac.in
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 877902ee5c938719299123aadaffdc2dbde2f1bf
Author: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
Date:   Tue Nov 11 16:13:33 2025 +0800

    EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection
    
    commit 281326be67252ac5794d1383f67526606b1d6b13 upstream.
    
    The current single-bit error injection mechanism flips bits directly in ECC RAM
    by performing write and read operations. When the ECC RAM is actively used by
    the Ethernet or USB controller, this approach sometimes trigger a false
    double-bit error.
    
    Switch both Ethernet and USB EDAC devices to use the INTTEST register
    (altr_edac_a10_device_inject_fops) for single-bit error injection, similar to
    the existing double-bit error injection method.
    
    Fixes: 064acbd4f4ab ("EDAC, altera: Add Stratix10 peripheral support")
    Signed-off-by: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Dinh Nguyen <dinguyen@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20251111081333.1279635-1-niravkumarlaxmidas.rabara@altera.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a4507829345a17bd08867ae65ee13429db11b2a
Author: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
Date:   Tue Nov 11 16:08:01 2025 +0800

    EDAC/altera: Handle OCRAM ECC enable after warm reset
    
    commit fd3ecda38fe0cb713d167b5477d25f6b350f0514 upstream.
    
    The OCRAM ECC is always enabled either by the BootROM or by the Secure Device
    Manager (SDM) during a power-on reset on SoCFPGA.
    
    However, during a warm reset, the OCRAM content is retained to preserve data,
    while the control and status registers are reset to their default values. As
    a result, ECC must be explicitly re-enabled after a warm reset.
    
    Fixes: 17e47dc6db4f ("EDAC/altera: Add Stratix10 OCRAM ECC support")
    Signed-off-by: Niravkumar L Rabara <niravkumarlaxmidas.rabara@altera.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Dinh Nguyen <dinguyen@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20251111080801.1279401-1-niravkumarlaxmidas.rabara@altera.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2181a24e85c31bb91899fcc1908bae1a452c2929
Author: Hans de Goede <hansg@kernel.org>
Date:   Sun Nov 2 20:09:21 2025 +0100

    spi: Try to get ACPI GPIO IRQ earlier
    
    commit 3cd2018e15b3d66d2187d92867e265f45ad79e6f upstream.
    
    Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the
    acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called
    on the SPI device.
    
    If there is no driver for the SPI device then the move to spi_probe()
    results in acpi_dev_gpio_irq_get() never getting called. This may
    cause problems by leaving the GPIO pin floating because this call is
    responsible for setting up the GPIO pin direction and/or bias according
    to the values from the ACPI tables.
    
    Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device()
    to ensure the GPIO pin is always correctly setup, while keeping the
    acpi_dev_gpio_irq_get() call added to spi_probe() to deal with
    -EPROBE_DEFER returns caused by the GPIO controller not having a driver
    yet.
    
    Link: https://bbs.archlinux.org/viewtopic.php?id=302348
    Fixes: d24cfee7f63d ("spi: Fix acpi deferred irq probe")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hansg@kernel.org>
    Link: https://patch.msgid.link/20251102190921.30068-1-hansg@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c81d0385500446efe48c305bbb83d47f2ae23a50
Author: Wei Yang <albinwyang@tencent.com>
Date:   Sat Oct 25 10:42:33 2025 +0800

    fs/proc: fix uaf in proc_readdir_de()
    
    commit 895b4c0c79b092d732544011c3cecaf7322c36a1 upstream.
    
    Pde is erased from subdir rbtree through rb_erase(), but not set the node
    to EMPTY, which may result in uaf access.  We should use RB_CLEAR_NODE()
    set the erased node to EMPTY, then pde_subdir_next() will return NULL to
    avoid uaf access.
    
    We found an uaf issue while using stress-ng testing, need to run testcase
    getdent and tun in the same time.  The steps of the issue is as follows:
    
    1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current
       pde is tun3;
    
    2) in the [time windows] unregister netdevice tun3 and tun2, and erase
       them from rbtree.  erase tun3 first, and then erase tun2.  the
       pde(tun2) will be released to slab;
    
    3) continue to getdent process, then pde_subdir_next() will return
       pde(tun2) which is released, it will case uaf access.
    
    CPU 0                                      |    CPU 1
    -------------------------------------------------------------------------
    traverse dir /proc/pid/net/dev_snmp6/      |   unregister_netdevice(tun->dev)   //tun3 tun2
    sys_getdents64()                           |
      iterate_dir()                            |
        proc_readdir()                         |
          proc_readdir_de()                    |     snmp6_unregister_dev()
            pde_get(de);                       |       proc_remove()
            read_unlock(&proc_subdir_lock);    |         remove_proc_subtree()
                                               |           write_lock(&proc_subdir_lock);
            [time window]                      |           rb_erase(&root->subdir_node, &parent->subdir);
                                               |           write_unlock(&proc_subdir_lock);
            read_lock(&proc_subdir_lock);      |
            next = pde_subdir_next(de);        |
            pde_put(de);                       |
            de = next;    //UAF                |
    
    rbtree of dev_snmp6
                            |
                        pde(tun3)
                         /    \
                      NULL  pde(tun2)
    
    Link: https://lkml.kernel.org/r/20251025024233.158363-1-albin_yang@163.com
    Signed-off-by: Wei Yang <albinwyang@tencent.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: wangzijie <wangzijie1@honor.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4b7210da22429765d19460d38c30eeca72656282
Author: Chuang Wang <nashuiliang@gmail.com>
Date:   Tue Nov 11 14:43:24 2025 +0800

    ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
    
    commit ac1499fcd40fe06479e9b933347b837ccabc2a40 upstream.
    
    The sit driver's packet transmission path calls: sit_tunnel_xmit() ->
    update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called
    to delete entries exceeding FNHE_RECLAIM_DEPTH+random.
    
    The race window is between fnhe_remove_oldest() selecting fnheX for
    deletion and the subsequent kfree_rcu(). During this time, the
    concurrent path's __mkroute_output() -> find_exception() can fetch the
    soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a
    new dst using a dst_hold(). When the original fnheX is freed via RCU,
    the dst reference remains permanently leaked.
    
    CPU 0                             CPU 1
    __mkroute_output()
      find_exception() [fnheX]
                                      update_or_create_fnhe()
                                        fnhe_remove_oldest() [fnheX]
      rt_bind_exception() [bind dst]
                                      RCU callback [fnheX freed, dst leak]
    
    This issue manifests as a device reference count leak and a warning in
    dmesg when unregistering the net device:
    
      unregister_netdevice: waiting for sitX to become free. Usage count = N
    
    Ido Schimmel provided the simple test validation method [1].
    
    The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().
    Since rt_bind_exception() checks this field, setting it to zero prevents
    the stale fnhe from being reused and bound to a new dst just before it
    is freed.
    
    [1]
    ip netns add ns1
    ip -n ns1 link set dev lo up
    ip -n ns1 address add 192.0.2.1/32 dev lo
    ip -n ns1 link add name dummy1 up type dummy
    ip -n ns1 route add 192.0.2.2/32 dev dummy1
    ip -n ns1 link add name gretap1 up arp off type gretap \
        local 192.0.2.1 remote 192.0.2.2
    ip -n ns1 route add 198.51.0.0/16 dev gretap1
    taskset -c 0 ip netns exec ns1 mausezahn gretap1 \
        -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
    taskset -c 2 ip netns exec ns1 mausezahn gretap1 \
        -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
    sleep 10
    ip netns pids ns1 | xargs kill
    ip netns del ns1
    
    Cc: stable@vger.kernel.org
    Fixes: 67d6d681e15b ("ipv4: make exception cache less predictible")
    Signed-off-by: Chuang Wang <nashuiliang@gmail.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20251111064328.24440-1-nashuiliang@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4ff921fbf089182d585ab746f2db42ef723ab8f
Author: Nate Karstens <nate.karstens@garmin.com>
Date:   Thu Nov 6 16:28:33 2025 -0600

    strparser: Fix signed/unsigned mismatch bug
    
    commit 4da4e4bde1c453ac5cc2dce5def81d504ae257ee upstream.
    
    The `len` member of the sk_buff is an unsigned int. This is cast to
    `ssize_t` (a signed type) for the first sk_buff in the comparison,
    but not the second sk_buff. On 32-bit systems, this can result in
    an integer underflow for certain values because unsigned arithmetic
    is being used.
    
    This appears to be an oversight: if the intention was to use unsigned
    arithmetic, then the first cast would have been omitted. The change
    ensures both len values are cast to `ssize_t`.
    
    The underflow causes an issue with ktls when multiple TLS PDUs are
    included in a single TCP segment. The mainline kernel does not use
    strparser for ktls anymore, but this is still useful for other
    features that still use strparser, and for backporting.
    
    Signed-off-by: Nate Karstens <nate.karstens@garmin.com>
    Cc: stable@vger.kernel.org
    Fixes: 43a0c6751a32 ("strparser: Stream parser for messages")
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://patch.msgid.link/20251106222835.1871628-1-nate.karstens@garmin.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d2cc86a025f216f5b68e8980c8a2614a9de139f
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date:   Tue Oct 28 12:51:25 2025 +0100

    gcov: add support for GCC 15
    
    commit ec4d11fc4b2dd4a2fa8c9d801ee9753b74623554 upstream.
    
    Using gcov on kernels compiled with GCC 15 results in truncated 16-byte
    long .gcda files with no usable data.  To fix this, update GCOV_COUNTERS
    to match the value defined by GCC 15.
    
    Tested with GCC 14.3.0 and GCC 15.2.0.
    
    Link: https://lkml.kernel.org/r/20251028115125.1319410-1-oberpar@linux.ibm.com
    Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Reported-by: Matthieu Baerts <matttbe@kernel.org>
    Closes: https://github.com/linux-test-project/lcov/issues/445
    Tested-by: Matthieu Baerts <matttbe@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 935a2dc8928670bb2c37e21025331e61ec48ccf4
Author: Olga Kornievskaia <okorniev@redhat.com>
Date:   Tue Oct 14 13:59:59 2025 -0400

    NFSD: free copynotify stateid in nfs4_free_ol_stateid()
    
    commit 4aa17144d5abc3c756883e3a010246f0dba8b468 upstream.
    
    Typically copynotify stateid is freed either when parent's stateid
    is being close/freed or in nfsd4_laundromat if the stateid hasn't
    been used in a lease period.
    
    However, in case when the server got an OPEN (which created
    a parent stateid), followed by a COPY_NOTIFY using that stateid,
    followed by a client reboot. New client instance while doing
    CREATE_SESSION would force expire previous state of this client.
    It leads to the open state being freed thru release_openowner->
    nfs4_free_ol_stateid() and it finds that it still has copynotify
    stateid associated with it. We currently print a warning and is
    triggerred
    
    WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]
    
    This patch, instead, frees the associated copynotify stateid here.
    
    If the parent stateid is freed (without freeing the copynotify
    stateids associated with it), it leads to the list corruption
    when laundromat ends up freeing the copynotify state later.
    
    [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
    [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink
    [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G    B   W           6.17.0-rc7+ #22 PREEMPT(voluntary)
    [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN
    [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024
    [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]
    [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200
    [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200
    [ 1626.861182] sp : ffff8000881d7a40
    [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200
    [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20
    [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8
    [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000
    [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065
    [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3
    [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000
    [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001
    [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000
    [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d
    [ 1626.868167] Call trace:
    [ 1626.868382]  __list_del_entry_valid_or_report+0x148/0x200 (P)
    [ 1626.868876]  _free_cpntf_state_locked+0xd0/0x268 [nfsd]
    [ 1626.869368]  nfs4_laundromat+0x6f8/0x1058 [nfsd]
    [ 1626.869813]  laundromat_main+0x24/0x60 [nfsd]
    [ 1626.870231]  process_one_work+0x584/0x1050
    [ 1626.870595]  worker_thread+0x4c4/0xc60
    [ 1626.870893]  kthread+0x2f8/0x398
    [ 1626.871146]  ret_from_fork+0x10/0x20
    [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)
    [ 1626.871892] SMP: stopping secondary CPUs
    
    Reported-by: rtm@csail.mit.edu
    Closes: https://lore.kernel.org/linux-nfs/d8f064c1-a26f-4eed-b4f0-1f7f608f415f@oracle.com/T/#t
    Fixes: 624322f1adc5 ("NFSD add COPY_NOTIFY operation")
    Cc: stable@vger.kernel.org
    Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d561463ea6f8e89394956c458eedc6aac7714d1
Author: Masami Ichikawa <masami256@gmail.com>
Date:   Sun Sep 21 14:31:02 2025 +0900

    HID: hid-ntrig: Prevent memory leak in ntrig_report_version()
    
    [ Upstream commit 53f731f5bba0cf03b751ccceb98b82fadc9ccd1e ]
    
    Use a scope-based cleanup helper for the buffer allocated with kmalloc()
    in ntrig_report_version() to simplify the cleanup logic and prevent
    memory leaks (specifically the !hid_is_usb()-case one).
    
    [jkosina@suse.com: elaborate on the actual existing leak]
    Fixes: 185c926283da ("HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()")
    Signed-off-by: Masami Ichikawa <masami256@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0521e694d5b80899fba8695881a6349f9bc538cb
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Nov 17 21:40:46 2025 +0000

    netfilter: nf_tables: reject duplicate device on updates
    
    commit cf5fb87fcdaaaafec55dcc0dc5a9e15ead343973 upstream.
    
    A chain/flowtable update with duplicated devices in the same batch is
    possible. Unfortunately, netdev event path only removes the first
    device that is found, leaving unregistered the hook of the duplicated
    device.
    
    Check if a duplicated device exists in the transaction batch, bail out
    with EEXIST in such case.
    
    WARNING is hit when unregistering the hook:
    
     [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150
     [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S                  6.16.0+ #170 PREEMPT(full)
     [...]
     [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150
    
    Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable")
    Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1417a57c5c0abd72fafb7e7fb6eb31e73bb4fed
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat Nov 1 16:25:48 2025 +0300

    mtd: onenand: Pass correct pointer to IRQ handler
    
    [ Upstream commit 97315e7c901a1de60e8ca9b11e0e96d0f9253e18 ]
    
    This was supposed to pass "onenand" instead of "&onenand" with the
    ampersand.  Passing a random stack address which will be gone when the
    function ends makes no sense.  However the good thing is that the pointer
    is never used, so this doesn't cause a problem at run time.
    
    Fixes: e23abf4b7743 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 189f0cb068b8caa77d504eaa334c6c5b1bf82a3a
Author: Eric Biggers <ebiggers@kernel.org>
Date:   Tue Nov 11 12:29:49 2025 -0800

    lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN
    
    commit 44e8241c51f762aafa50ed116da68fd6ecdcc954 upstream.
    
    On big endian arm kernels, the arm optimized Curve25519 code produces
    incorrect outputs and fails the Curve25519 test.  This has been true
    ever since this code was added.
    
    It seems that hardly anyone (or even no one?) actually uses big endian
    arm kernels.  But as long as they're ostensibly supported, we should
    disable this code on them so that it's not accidentally used.
    
    Note: for future-proofing, use !CPU_BIG_ENDIAN instead of
    CPU_LITTLE_ENDIAN.  Both of these are arch-specific options that could
    get removed in the future if big endian support gets dropped.
    
    Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation")
    Cc: stable@vger.kernel.org
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20251104054906.716914-1-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 788e5385d0ff69cdba1cabccb9dab8d9647b9239
Author: Jakub Acs <acsjakub@amazon.de>
Date:   Fri Nov 7 12:19:05 2025 +0000

    mm/ksm: fix flag-dropping behavior in ksm_madvise
    
    [ Upstream commit f04aad36a07cc17b7a5d5b9a2d386ce6fae63e93 ]
    
    syzkaller discovered the following crash: (kernel BUG)
    
    [   44.607039] ------------[ cut here ]------------
    [   44.607422] kernel BUG at mm/userfaultfd.c:2067!
    [   44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
    [   44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)
    [   44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
    [   44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
    
    <snip other registers, drop unreliable trace>
    
    [   44.617726] Call Trace:
    [   44.617926]  <TASK>
    [   44.619284]  userfaultfd_release+0xef/0x1b0
    [   44.620976]  __fput+0x3f9/0xb60
    [   44.621240]  fput_close_sync+0x110/0x210
    [   44.622222]  __x64_sys_close+0x8f/0x120
    [   44.622530]  do_syscall_64+0x5b/0x2f0
    [   44.622840]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [   44.623244] RIP: 0033:0x7f365bb3f227
    
    Kernel panics because it detects UFFD inconsistency during
    userfaultfd_release_all().  Specifically, a VMA which has a valid pointer
    to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
    
    The inconsistency is caused in ksm_madvise(): when user calls madvise()
    with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,
    it accidentally clears all flags stored in the upper 32 bits of
    vma->vm_flags.
    
    Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and
    int are 32-bit wide.  This setup causes the following mishap during the &=
    ~VM_MERGEABLE assignment.
    
    VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000.
    After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then
    promoted to unsigned long before the & operation.  This promotion fills
    upper 32 bits with leading 0s, as we're doing unsigned conversion (and
    even for a signed conversion, this wouldn't help as the leading bit is 0).
    & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff
    instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears
    the upper 32-bits of its value.
    
    Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the
    BIT() macro.
    
    Note: other VM_* flags are not affected: This only happens to the
    VM_MERGEABLE flag, as the other VM_* flags are all constants of type int
    and after ~ operation, they end up with leading 1 and are thus converted
    to unsigned long with leading 1s.
    
    Note 2:
    After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is
    no longer a kernel BUG, but a WARNING at the same place:
    
    [   45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
    
    but the root-cause (flag-drop) remains the same.
    
    [akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
      Link: https://lore.kernel.org/oe-kbuild-all/202510030449.VfSaAjvd-lkp@intel.com/
    Link: https://lkml.kernel.org/r/20251001090353.57523-2-acsjakub@amazon.de
    Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode")
    Signed-off-by: Jakub Acs <acsjakub@amazon.de>
    Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Acked-by: SeongJae Park <sj@kernel.org>
    Tested-by: Alice Ryhl <aliceryhl@google.com>
    Tested-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
    Cc: Xu Xin <xu.xin16@zte.com.cn>
    Cc: Chengming Zhou <chengming.zhou@linux.dev>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    [ acsjakub: drop rust-compatibility change (no rust in 5.10) ]
    Signed-off-by: Jakub Acs <acsjakub@amazon.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5c426a83685f249da0c6d3c049c5f4e82b44f9a
Author: Christoph Hellwig <hch@lst.de>
Date:   Sun Nov 9 11:47:03 2025 +0000

    fsdax: mark the iomap argument to dax_iomap_sector as const
    
    [ Upstream commit 7e4f4b2d689d959b03cb07dfbdb97b9696cb1076 ]
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Signed-off-by: Eliav Farber <farbere@amazon.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5c08965ab96b16361e69a1e2a0e89dbcb99b5a6
Author: Haein Lee <lhi0729@kaist.ac.kr>
Date:   Wed Nov 12 00:37:54 2025 +0900

    ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd
    
    [ Upstream commit 632108ec072ad64c8c83db6e16a7efee29ebfb74 ]
    
    In snd_usb_create_streams(), for UAC version 3 devices, the Interface
    Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this
    call fails, a fallback routine attempts to obtain the IAD from the next
    interface and sets a BADD profile. However, snd_usb_mixer_controls_badd()
    assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,
    without performing a NULL check. This can lead to a NULL pointer
    dereference when usb_ifnum_to_if() fails to find the interface descriptor.
    
    This patch adds a NULL pointer check after calling usb_ifnum_to_if() in
    snd_usb_mixer_controls_badd() to prevent the dereference.
    
    This issue was discovered by syzkaller, which triggered the bug by sending
    a crafted USB device descriptor.
    
    Fixes: 17156f23e93c ("ALSA: usb: add UAC3 BADD profiles support")
    Signed-off-by: Haein Lee <lhi0729@kaist.ac.kr>
    Link: https://patch.msgid.link/vwhzmoba9j2f.vwhzmob9u9e2.g6@dooray.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54d458b244893e47bda52ec3943fdfbc8d7d068b
Author: Ian Forbes <ian.forbes@broadcom.com>
Date:   Tue Oct 21 14:01:28 2025 -0500

    drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE
    
    [ Upstream commit 32b415a9dc2c212e809b7ebc2b14bc3fbda2b9af ]
    
    This data originates from userspace and is used in buffer offset
    calculations which could potentially overflow causing an out-of-bounds
    access.
    
    Fixes: 8ce75f8ab904 ("drm/vmwgfx: Update device includes for DX device functionality")
    Reported-by: Rohit Keshri <rkeshri@redhat.com>
    Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
    Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Link: https://patch.msgid.link/20251021190128.13014-1-ian.forbes@broadcom.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fa6c9142a614b0d30e65c576b0597f110f65baf
Author: Haotian Zhang <vulab@iscas.ac.cn>
Date:   Wed Nov 5 14:22:46 2025 +0800

    ASoC: cs4271: Fix regulator leak on probe failure
    
    [ Upstream commit 6b6eddc63ce871897d3a5bc4f8f593e698aef104 ]
    
    The probe function enables regulators at the beginning
    but fails to disable them in its error handling path.
    If any operation after enabling the regulators fails,
    the probe will exit with an error, leaving the regulators
    permanently enabled, which could lead to a resource leak.
    
    Add a proper error handling path to call regulator_bulk_disable()
    before returning an error.
    
    Fixes: 9a397f473657 ("ASoC: cs4271: add regulator consumer support")
    Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
    Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://patch.msgid.link/20251105062246.1955-1-vulab@iscas.ac.cn
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88699fbde4268f8d5f479c3dbfff13e924b11dbf
Author: Haotian Zhang <vulab@iscas.ac.cn>
Date:   Wed Oct 29 01:28:28 2025 +0800

    regulator: fixed: fix GPIO descriptor leak on register failure
    
    [ Upstream commit 636f4618b1cd96f6b5a2b8c7c4f665c8533ecf13 ]
    
    In the commit referenced by the Fixes tag,
    devm_gpiod_get_optional() was replaced by manual
    GPIO management, relying on the regulator core to release the
    GPIO descriptor. However, this approach does not account for the
    error path: when regulator registration fails, the core never
    takes over the GPIO, resulting in a resource leak.
    
    Add gpiod_put() before returning on regulator registration failure.
    
    Fixes: 5e6f3ae5c13b ("regulator: fixed: Let core handle GPIO descriptor")
    Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
    Link: https://patch.msgid.link/20251028172828.625-1-vulab@iscas.ac.cn
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 309fba8de9edcd636a9d11d296a76a6038276d8f
Author: Chris Morgan <macromorgan@hotmail.com>
Date:   Wed Jul 21 11:57:16 2021 -0500

    regulator: fixed: use dev_err_probe for register
    
    [ Upstream commit d0f95e6496a974a890df5eda65ffaee66ab0dc73 ]
    
    Instead of returning error directly, use dev_err_probe. This avoids
    messages in the dmesg log for devices which will be probed again later.
    
    Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
    Link: https://lore.kernel.org/r/20210721165716.19915-1-macroalpha82@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 636f4618b1cd ("regulator: fixed: fix GPIO descriptor leak on register failure")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1c1f2cfdae12a787e17f2bd654e0b6716a78e06
Author: Shuai Xue <xueshuai@linux.alibaba.com>
Date:   Sat Sep 13 10:32:24 2025 +0800

    acpi,srat: Fix incorrect device handle check for Generic Initiator
    
    [ Upstream commit 7c3643f204edf1c5edb12b36b34838683ee5f8dc ]
    
    The Generic Initiator Affinity Structure in SRAT table uses device
    handle type field to indicate the device type. According to ACPI
    specification, the device handle type value of 1 represents PCI device,
    not 0.
    
    Fixes: 894c26a1c274 ("ACPI: Support Generic Initiator only domains")
    Reported-by: Wu Zongyong <wuzongyong@linux.alibaba.com>
    Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
    Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
    Link: https://patch.msgid.link/20250913023224.39281-1-xueshuai@linux.alibaba.com
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cfa9a80851b3c0f592b64a70c4cb93a7b6958f6
Author: Pauli Virtanen <pav@iki.fi>
Date:   Mon Nov 3 20:29:48 2025 +0200

    Bluetooth: L2CAP: export l2cap_chan_hold for modules
    
    [ Upstream commit e060088db0bdf7932e0e3c2d24b7371c4c5b867c ]
    
    l2cap_chan_put() is exported, so export also l2cap_chan_hold() for
    modules.
    
    l2cap_chan_hold() has use case in net/bluetooth/6lowpan.c
    
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86dad148a64720de8cfa11ff3836db387b6f5723
Author: Felix Maurer <fmaurer@redhat.com>
Date:   Tue Nov 11 17:29:32 2025 +0100

    hsr: Fix supervision frame sending on HSRv0
    
    [ Upstream commit 96a3a03abf3d8cc38cd9cb0d280235fbcf7c3f7f ]
    
    On HSRv0, no supervision frames were sent. The supervison frames were
    generated successfully, but failed the check for a sufficiently long mac
    header, i.e., at least sizeof(struct hsr_ethhdr), in hsr_fill_frame_info()
    because the mac header only contained the ethernet header.
    
    Fix this by including the HSR header in the mac header when generating HSR
    supervision frames. Note that the mac header now also includes the TLV
    fields. This matches how we set the headers on rx and also the size of
    struct hsrv0_ethhdr_sp.
    
    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Closes: https://lore.kernel.org/netdev/aMONxDXkzBZZRfE5@fedora/
    Fixes: 9cfb5e7f0ded ("net: hsr: fix hsr_init_sk() vs network/transport headers.")
    Signed-off-by: Felix Maurer <fmaurer@redhat.com>
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://patch.msgid.link/4354114fea9a642fe71f49aeeb6c6159d1d61840.1762876095.git.fmaurer@redhat.com
    Tested-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dca97429671331f8ac4395cb0b33f0cfa352309b
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Nov 9 16:12:15 2025 +0000

    net_sched: limit try_bulk_dequeue_skb() batches
    
    [ Upstream commit 0345552a653ce5542affeb69ac5aa52177a5199b ]
    
    After commit 100dfa74cad9 ("inet: dev_queue_xmit() llist adoption")
    I started seeing many qdisc requeues on IDPF under high TX workload.
    
    $ tc -s qd sh dev eth1 handle 1: ; sleep 1; tc -s qd sh dev eth1 handle 1:
    qdisc mq 1: root
     Sent 43534617319319 bytes 268186451819 pkt (dropped 0, overlimits 0 requeues 3532840114)
     backlog 1056Kb 6675p requeues 3532840114
    qdisc mq 1: root
     Sent 43554665866695 bytes 268309964788 pkt (dropped 0, overlimits 0 requeues 3537737653)
     backlog 781164b 4822p requeues 3537737653
    
    This is caused by try_bulk_dequeue_skb() being only limited by BQL budget.
    
    perf record -C120-239 -e qdisc:qdisc_dequeue sleep 1 ; perf script
    ...
     netperf 75332 [146]  2711.138269: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1292 skbaddr=0xff378005a1e9f200
     netperf 75332 [146]  2711.138953: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1213 skbaddr=0xff378004d607a500
     netperf 75330 [144]  2711.139631: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1233 skbaddr=0xff3780046be20100
     netperf 75333 [147]  2711.140356: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1093 skbaddr=0xff37800514845b00
     netperf 75337 [151]  2711.141037: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1353 skbaddr=0xff37800460753300
     netperf 75337 [151]  2711.141877: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1367 skbaddr=0xff378004e72c7b00
     netperf 75330 [144]  2711.142643: qdisc:qdisc_dequeue: dequeue ifindex=5 qdisc handle=0x80150000 parent=0x10013 txq_state=0x0 packets=1202 skbaddr=0xff3780045bd60000
    ...
    
    This is bad because :
    
    1) Large batches hold one victim cpu for a very long time.
    
    2) Driver often hit their own TX ring limit (all slots are used).
    
    3) We call dev_requeue_skb()
    
    4) Requeues are using a FIFO (q->gso_skb), breaking qdisc ability to
       implement FQ or priority scheduling.
    
    5) dequeue_skb() gets packets from q->gso_skb one skb at a time
       with no xmit_more support. This is causing many spinlock games
       between the qdisc and the device driver.
    
    Requeues were supposed to be very rare, lets keep them this way.
    
    Limit batch sizes to /proc/sys/net/core/dev_weight (default 64) as
    __qdisc_run() was designed to use.
    
    Fixes: 5772e9a3463b ("qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
    Link: https://patch.msgid.link/20251109161215.2574081-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c81c68fc788f74c2911d8a4021f7166a4cf0438
Author: Gal Pressman <gal@nvidia.com>
Date:   Sun Nov 9 11:37:52 2025 +0200

    net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps
    
    [ Upstream commit 43b27d1bd88a4bce34ec2437d103acfae9655f9e ]
    
    Add validation to reject rates exceeding 255 Gbps that would overflow
    the 8 bits max bandwidth field.
    
    Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate")
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Nimrod Oren <noren@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://patch.msgid.link/1762681073-1084058-5-git-send-email-tariqt@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc9dddefa441de7e82b19b4cb3fd4f5981614bf2
Author: Gal Pressman <gal@nvidia.com>
Date:   Sun Nov 9 11:37:51 2025 +0200

    net/mlx5e: Fix maxrate wraparound in threshold between units
    
    [ Upstream commit a7bf4d5063c7837096aab2853224eb23628514d9 ]
    
    The previous calculation used roundup() which caused an overflow for
    rates between 25.5Gbps and 26Gbps.
    For example, a rate of 25.6Gbps would result in using 100Mbps units with
    value of 256, which would overflow the 8 bits field.
    
    Simplify the upper_limit_mbps calculation by removing the
    unnecessary roundup, and adjust the comparison to use <= to correctly
    handle the boundary condition.
    
    Fixes: d8880795dabf ("net/mlx5e: Implement DCBNL IEEE max rate")
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Nimrod Oren <noren@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://patch.msgid.link/1762681073-1084058-4-git-send-email-tariqt@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e3644ef147bf7140259dfa4cace680c9b26fe8b
Author: Ranganath V N <vnranganath.20@gmail.com>
Date:   Sun Nov 9 14:43:36 2025 +0530

    net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak
    
    [ Upstream commit ce50039be49eea9b4cd8873ca6eccded1b4a130a ]
    
    Fix a KMSAN kernel-infoleak detected  by the syzbot .
    
    [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
    
    In tcf_ife_dump(), the variable 'opt' was partially initialized using a
    designatied initializer. While the padding bytes are reamined
    uninitialized. nla_put() copies the entire structure into a
    netlink message, these uninitialized bytes leaked to userspace.
    
    Initialize the structure with memset before assigning its fields
    to ensure all members and padding are cleared prior to beign copied.
    
    This change silences the KMSAN report and prevents potential information
    leaks from the kernel memory.
    
    This fix has been tested and validated by syzbot. This patch closes the
    bug reported at the following syzkaller link and ensures no infoleak.
    
    Reported-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=0c85cae3350b7d486aee
    Tested-by: syzbot+0c85cae3350b7d486aee@syzkaller.appspotmail.com
    Fixes: ef6980b6becb ("introduce IFE action")
    Signed-off-by: Ranganath V N <vnranganath.20@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20251109091336.9277-3-vnranganath.20@gmail.com
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecc09c54e052cf27e45df2ba15674e5e1025434b
Author: Benjamin Berg <benjamin.berg@intel.com>
Date:   Mon Nov 10 14:26:18 2025 +0200

    wifi: mac80211: skip rate verification for not captured PSDUs
    
    [ Upstream commit 7fe0d21f5633af8c3fab9f0ef0706c6156623484 ]
    
    If for example the sniffer did not follow any AIDs in an MU frame, then
    some of the information may not be filled in or is even expected to be
    invalid. As an example, in that case it is expected that Nss is zero.
    
    Fixes: 2ff5e52e7836 ("radiotap: add 0-length PSDU "not captured" type")
    Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://patch.msgid.link/20251110142554.83a2858ee15b.I9f78ce7984872f474722f9278691ae16378f0a3e@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cffad4756cf9dd61a96108710d90d5f53e480945
Author: Buday Csaba <buday.csaba@prolan.hu>
Date:   Sat Nov 8 07:49:22 2025 +0100

    net: mdio: fix resource leak in mdiobus_register_device()
    
    [ Upstream commit e6ca8f533ed41129fcf052297718f417f021cc7d ]
    
    Fix a possible leak in mdiobus_register_device() when both a
    reset-gpio and a reset-controller are present.
    Clean up the already claimed reset-gpio, when the registration of
    the reset-controller fails, so when an error code is returned, the
    device retains its state before the registration attempt.
    
    Link: https://lore.kernel.org/all/20251106144603.39053c81@kernel.org/
    Fixes: 71dd6c0dff51 ("net: phy: add support for reset-controller")
    Signed-off-by: Buday Csaba <buday.csaba@prolan.hu>
    Link: https://patch.msgid.link/4b419377f8dd7d2f63f919d0f74a336c734f8fff.1762584481.git.buday.csaba@prolan.hu
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2e77c789c234e7fe49057d2ced8f32e2d2c7901
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Fri Nov 7 06:40:25 2025 +0000

    tipc: Fix use-after-free in tipc_mon_reinit_self().
    
    [ Upstream commit 0725e6afb55128be21a2ca36e9674f573ccec173 ]
    
    syzbot reported use-after-free of tipc_net(net)->monitors[]
    in tipc_mon_reinit_self(). [0]
    
    The array is protected by RTNL, but tipc_mon_reinit_self()
    iterates over it without RTNL.
    
    tipc_mon_reinit_self() is called from tipc_net_finalize(),
    which is always under RTNL except for tipc_net_finalize_work().
    
    Let's hold RTNL in tipc_net_finalize_work().
    
    [0]:
    BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
    BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162
    Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989
    
    CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
    Workqueue: events tipc_net_finalize_work
    Call Trace:
     <TASK>
     dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:378 [inline]
     print_report+0xca/0x240 mm/kasan/report.c:482
     kasan_report+0x118/0x150 mm/kasan/report.c:595
     __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568
     kasan_check_byte include/linux/kasan.h:399 [inline]
     lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842
     __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
     _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162
     rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline]
     rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline]
     rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244
     rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243
     write_lock_bh include/linux/rwlock_rt.h:99 [inline]
     tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718
     tipc_net_finalize+0x115/0x190 net/tipc/net.c:140
     process_one_work kernel/workqueue.c:3236 [inline]
     process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319
     worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400
     kthread+0x70e/0x8a0 kernel/kthread.c:463
     ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
     </TASK>
    
    Allocated by task 6089:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
     poison_kmalloc_redzone mm/kasan/common.c:388 [inline]
     __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405
     kasan_kmalloc include/linux/kasan.h:260 [inline]
     __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407
     kmalloc_noprof include/linux/slab.h:905 [inline]
     kzalloc_noprof include/linux/slab.h:1039 [inline]
     tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657
     tipc_enable_bearer net/tipc/bearer.c:357 [inline]
     __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047
     __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline]
     tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393
     tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline]
     tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321
     genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115
     genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
     genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210
     netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552
     genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
     netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
     netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346
     netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896
     sock_sendmsg_nosec net/socket.c:714 [inline]
     __sock_sendmsg+0x21c/0x270 net/socket.c:729
     ____sys_sendmsg+0x508/0x820 net/socket.c:2614
     ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
     __sys_sendmsg net/socket.c:2700 [inline]
     __do_sys_sendmsg net/socket.c:2705 [inline]
     __se_sys_sendmsg net/socket.c:2703 [inline]
     __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 6088:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
     kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
     poison_slab_object mm/kasan/common.c:243 [inline]
     __kasan_slab_free+0x5b/0x80 mm/kasan/common.c:275
     kasan_slab_free include/linux/kasan.h:233 [inline]
     slab_free_hook mm/slub.c:2422 [inline]
     slab_free mm/slub.c:4695 [inline]
     kfree+0x195/0x550 mm/slub.c:4894
     tipc_l2_device_event+0x380/0x650 net/tipc/bearer.c:-1
     notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85
     call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
     call_netdevice_notifiers net/core/dev.c:2281 [inline]
     unregister_netdevice_many_notify+0x14d7/0x1fe0 net/core/dev.c:12166
     unregister_netdevice_many net/core/dev.c:12229 [inline]
     unregister_netdevice_queue+0x33c/0x380 net/core/dev.c:12073
     unregister_netdevice include/linux/netdevice.h:3385 [inline]
     __tun_detach+0xe4d/0x1620 drivers/net/tun.c:621
     tun_detach drivers/net/tun.c:637 [inline]
     tun_chr_close+0x10d/0x1c0 drivers/net/tun.c:3433
     __fput+0x458/0xa80 fs/file_table.c:468
     task_work_run+0x1d4/0x260 kernel/task_work.c:227
     resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
     exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:43
     exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
     syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
     syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
     do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 46cb01eeeb86 ("tipc: update mon's self addr when node addr generated")
    Reported-by: syzbot+d7dad7fd4b3921104957@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/690c323a.050a0220.baf87.007f.GAE@google.com/
    Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20251107064038.2361188-1-kuniyu@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8aea37907f5547bf5c2fe460601c682aa0350041
Author: D. Wythe <alibuda@linux.alibaba.com>
Date:   Fri Nov 7 10:40:29 2025 +0800

    net/smc: fix mismatch between CLC header and proposal
    
    [ Upstream commit ec33f2e5a2d0dbbfd71435209aee812fdc9369b8 ]
    
    The current CLC proposal message construction uses a mix of
    `ini->smc_type_v1/v2` and `pclc_base->hdr.typev1/v2` to decide whether
    to include optional extensions (IPv6 prefix extension for v1, and v2
    extension). This leads to a critical inconsistency: when
    `smc_clc_prfx_set()` fails - for example, in IPv6-only environments with
    only link-local addresses, or when the local IP address and the outgoing
    interface’s network address are not in the same subnet.
    
    As a result, the proposal message is assembled using the stale
    `ini->smc_type_v1` value—causing the IPv6 prefix extension to be
    included even though the header indicates v1 is not supported.
    The peer then receives a malformed CLC proposal where the header type
    does not match the payload, and immediately resets the connection.
    
    The fix ensures consistency between the CLC header flags and the actual
    payload by synchronizing `ini->smc_type_v1` with `pclc_base->hdr.typev1`
    when prefix setup fails.
    
    Fixes: 8c3dca341aea ("net/smc: build and send V2 CLC proposal")
    Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Link: https://patch.msgid.link/20251107024029.88753-1-alibuda@linux.alibaba.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 834e65be429c0fa4f9bb5945064bd57f18ed2187
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Nov 6 11:10:54 2025 +0000

    sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto
    
    [ Upstream commit 1534ff77757e44bcc4b98d0196bc5c0052fce5fa ]
    
    syzbot reported a possible shift-out-of-bounds [1]
    
    Blamed commit added rto_alpha_max and rto_beta_max set to 1000.
    
    It is unclear if some sctp users are setting very large rto_alpha
    and/or rto_beta.
    
    In order to prevent user regression, perform the test at run time.
    
    Also add READ_ONCE() annotations as sysctl values can change under us.
    
    [1]
    
    UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41
    shift exponent 64 is too large for 32-bit type 'unsigned int'
    CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:94 [inline]
      dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
      ubsan_epilogue lib/ubsan.c:233 [inline]
      __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494
      sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509
      sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502
      sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338
      sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline]
      sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]
    
    Fixes: b58537a1f562 ("net: sctp: fix permissions for rto_alpha and rto_beta knobs")
    Reported-by: syzbot+f8c46c8b2b7f6e076e99@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/690c81ae.050a0220.3d0d33.014e.GAE@google.com/T/#u
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Link: https://patch.msgid.link/20251106111054.3288127-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcfbddcc7c2edff797ca158240cc49a54a826dc5
Author: Pauli Virtanen <pav@iki.fi>
Date:   Mon Nov 3 20:29:49 2025 +0200

    Bluetooth: 6lowpan: Don't hold spin lock over sleeping functions
    
    [ Upstream commit 98454bc812f3611551e4b1f81732da4aa7b9597e ]
    
    disconnect_all_peers() calls sleeping function (l2cap_chan_close) under
    spinlock.  Holding the lock doesn't actually do any good -- we work on a
    local copy of the list, and the lock doesn't protect against peer->chan
    having already been freed.
    
    Fix by taking refcounts of peer->chan instead.  Clean up the code and
    old comments a bit.
    
    Take devices_lock instead of RCU, because the kfree_rcu();
    l2cap_chan_put(); construct in chan_close_cb() does not guarantee
    peer->chan is necessarily valid in RCU.
    
    Also take l2cap_chan_lock() which is required for l2cap_chan_close().
    
    Log: (bluez 6lowpan-tester Client Connect - Disable)
    ------
    BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575
    ...
    <TASK>
    ...
    l2cap_send_disconn_req (net/bluetooth/l2cap_core.c:938 net/bluetooth/l2cap_core.c:1495)
    ...
    ? __pfx_l2cap_chan_close (net/bluetooth/l2cap_core.c:809)
    do_enable_set (net/bluetooth/6lowpan.c:1048 net/bluetooth/6lowpan.c:1068)
    ------
    
    Fixes: 90305829635d ("Bluetooth: 6lowpan: Converting rwlocks to use RCU")
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7628d4173bacf1baf69e87d89d18a0cb45b99068
Author: Pauli Virtanen <pav@iki.fi>
Date:   Mon Nov 3 20:29:47 2025 +0200

    Bluetooth: 6lowpan: fix BDADDR_LE vs ADDR_LE_DEV address type confusion
    
    [ Upstream commit b454505bf57a2e4f5d49951d4deb03730a9348d9 ]
    
    Bluetooth 6lowpan.c confuses BDADDR_LE and ADDR_LE_DEV address types,
    e.g. debugfs "connect" command takes the former, and "disconnect" and
    "connect" to already connected device take the latter.  This is due to
    using same value both for l2cap_chan_connect and hci_conn_hash_lookup_le
    which take different dst_type values.
    
    Fix address type passed to hci_conn_hash_lookup_le().
    
    Retain the debugfs API difference between "connect" and "disconnect"
    commands since it's been like this since 2015 and nobody apparently
    complained.
    
    Fixes: f5ad4ffceba0 ("Bluetooth: 6lowpan: Use hci_conn_hash_lookup_le() when possible")
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 973e0271754c77db3e1b6b69adf2de85a79a4c8b
Author: Pauli Virtanen <pav@iki.fi>
Date:   Mon Nov 3 20:29:46 2025 +0200

    Bluetooth: 6lowpan: reset link-local header on ipv6 recv path
    
    [ Upstream commit 3b78f50918276ab28fb22eac9aa49401ac436a3b ]
    
    Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local
    header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW
    
    Add missing skb_reset_mac_header() for uncompressed ipv6 RX path.
    
    For the compressed one, it is done in lowpan_header_decompress().
    
    Log: (BlueZ 6lowpan-tester Client Recv Raw - Success)
    ------
    kernel BUG at net/core/skbuff.c:212!
    Call Trace:
    <IRQ>
    ...
    packet_rcv (net/packet/af_packet.c:2152)
    ...
    <TASK>
    __local_bh_enable_ip (kernel/softirq.c:407)
    netif_rx (net/core/dev.c:5648)
    chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359)
    ------
    
    Fixes: 18722c247023 ("Bluetooth: Enable 6LoWPAN support for BT LE devices")
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Pauli Virtanen <pav@iki.fi>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f858f004bc343a7ae9f2533bbb2a3ab27428532f
Author: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
Date:   Wed Nov 5 14:28:41 2025 -0500

    Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF
    
    [ Upstream commit 23d22f2f71768034d6ef86168213843fc49bf550 ]
    
    There is a KASAN: slab-use-after-free read in btusb_disconnect().
    Calling "usb_driver_release_interface(&btusb_driver, data->intf)" will
    free the btusb data associated with the interface. The same data is
    then used later in the function, hence the UAF.
    
    Fix by moving the accesses to btusb data to before the data is free'd.
    
    Reported-by: syzbot+2fc81b50a4f8263a159b@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=2fc81b50a4f8263a159b
    Tested-by: syzbot+2fc81b50a4f8263a159b@syzkaller.appspotmail.com
    Fixes: fd913ef7ce619 ("Bluetooth: btusb: Add out-of-band wakeup support")
    Signed-off-by: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee98fbbfcfe380841787b1ca2c44ef85683f33cd
Author: Wei Fang <wei.fang@nxp.com>
Date:   Thu Nov 6 10:14:21 2025 +0800

    net: fec: correct rx_bytes statistic for the case SHIFT16 is set
    
    [ Upstream commit ad17e7e92a7c52ce70bb764813fcf99464f96903 ]
    
    Two additional bytes in front of each frame received into the RX FIFO if
    SHIFT16 is set, so we need to subtract the extra two bytes from pkt_len
    to correct the statistic of rx_bytes.
    
    Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware")
    Signed-off-by: Wei Fang <wei.fang@nxp.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Link: https://patch.msgid.link/20251106021421.2096585-1-wei.fang@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fa3aec402a88b4c5b2df2882f36bd7dbe0ed79e
Author: Sharique Mohammad <sharq0406@gmail.com>
Date:   Wed Oct 15 15:42:15 2025 +0200

    ASoC: max98090/91: fixed max98091 ALSA widget powering up/down
    
    [ Upstream commit 7a37291ed40a33a5f6c3d370fdde5ee0d8f7d0e4 ]
    
    The widgets DMIC3_ENA and DMIC4_ENA must be defined in the DAPM
    suppy widget, just like DMICL_ENA and DMICR_ENA. Whenever they
    are turned on or off, the required startup or shutdown sequences
    must be taken care by the max98090_shdn_event.
    
    Signed-off-by: Sharique Mohammad <sharq0406@gmail.com>
    Link: https://patch.msgid.link/20251015134215.750001-1-sharq0406@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdedfde2e0db77bd1623152ecdaf95130d6e96b3
Author: Tristan Lobb <tristan.lobb@it-lobb.de>
Date:   Sun Sep 28 18:25:43 2025 +0200

    HID: quirks: avoid Cooler Master MM712 dongle wakeup bug
    
    [ Upstream commit 0be4253bf878d9aaa2b96031ac8683fceeb81480 ]
    
    The Cooler Master Mice Dongle includes a vendor defined HID interface
    alongside its mouse interface. Not polling it will cause the mouse to
    stop responding to polls on any interface once woken up again after
    going into power saving mode.
    
    Add the HID_QUIRK_ALWAYS_POLL quirk alongside the Cooler Master VID and
    the Dongle's PID.
    
    Signed-off-by: Tristan Lobb <tristan.lobb@it-lobb.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9822045d862b651ddac3d3fa3447555926be74f
Author: Joshua Watt <jpewhacker@gmail.com>
Date:   Thu Oct 9 15:48:04 2025 -0600

    NFS4: Fix state renewals missing after boot
    
    [ Upstream commit 9bb3baa9d1604cd20f49ae7dac9306b4037a0e7a ]
    
    Since the last renewal time was initialized to 0 and jiffies start
    counting at -5 minutes, any clients connected in the first 5 minutes
    after a reboot would have their renewal timer set to a very long
    interval. If the connection was idle, this would result in the client
    state timing out on the server and the next call to the server would
    return NFS4ERR_BADSESSION.
    
    Fix this by initializing the last renewal time to the current jiffies
    instead of 0.
    
    Signed-off-by: Joshua Watt <jpewhacker@gmail.com>
    Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e828122d61777bbd3b9e73a3d45806cf05668c5
Author: Danil Skrebenkov <danil.skrebenkov@cloudbear.ru>
Date:   Fri Sep 19 16:28:46 2025 +0300

    RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid rfence errors
    
    [ Upstream commit ae9e9f3d67dcef7582a4524047b01e33c5185ddb ]
    
    openSBI v1.7 adds harts checks for ipi operations. Especially it
    adds comparison between hmask passed as an argument from linux
    and mask of online harts (from openSBI side). If they don't
    fit each other the error occurs.
    
    When cpu is offline, cpu_online_mask is explicitly cleared in
    __cpu_disable. However, there is no explicit clearing of
    mm_cpumask. mm_cpumask is used for rfence operations that
    call openSBI RFENCE extension which uses ipi to remote harts.
    If hart is offline there may be error if mask of linux is not
    as mask of online harts in openSBI.
    
    this patch adds explicit clearing of mm_cpumask for offline hart.
    
    Signed-off-by: Danil Skrebenkov <danil.skrebenkov@cloudbear.ru>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Link: https://lore.kernel.org/r/20250919132849.31676-1-danil.skrebenkov@cloudbear.ru
    [pjw@kernel.org: rewrote subject line for clarity]
    Signed-off-by: Paul Walmsley <pjw@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d7c1d1e2108ec6c4d43bb7ae4b4c07bdaefbf2e
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Nov 6 11:50:00 2025 +0100

    compiler_types: Move unused static inline functions warning to W=2
    
    [ Upstream commit 9818af18db4bfefd320d0fef41390a616365e6f7 ]
    
    Per Nathan, clang catches unused "static inline" functions in C files
    since commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
    inline functions for W=1 build").
    
    Linus said:
    
    > So I entirely ignore W=1 issues, because I think so many of the extra
    > warnings are bogus.
    >
    > But if this one in particular is causing more problems than most -
    > some teams do seem to use W=1 as part of their test builds - it's fine
    > to send me a patch that just moves bad warnings to W=2.
    >
    > And if anybody uses W=2 for their test builds, that's THEIR problem..
    
    Here is the change to bump the warning from W=1 to W=2.
    
    Fixes: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build")
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://patch.msgid.link/20251106105000.2103276-1-andriy.shevchenko@linux.intel.com
    [nathan: Adjust comment as well]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6304484933948b20700053854c5f8f8d8276db9d
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Fri May 9 09:17:04 2025 +0200

    extcon: adc-jack: Cleanup wakeup source only if it was enabled
    
    commit 92bac7d4de9c07933f6b76d8f1c7f8240f911f4f upstream.
    
    Driver in the probe enables wakeup source conditionally, so the cleanup
    path should do the same - do not release the wakeup source memory if it
    was not allocated.
    
    Link: https://lore.kernel.org/lkml/20250509071703.39442-2-krzysztof.kozlowski@linaro.org/
    Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Closes: https://lore.kernel.org/r/22aaebb7-553b-4571-8a43-58a523241082@wanadoo.fr/
    Fixes: 78b6a991eb6c ("extcon: adc-jack: Fix wakeup source leaks on device unbind")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51ff413288725ccff0f8913d97df44eb1dc8fa0d
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Nov 3 12:11:24 2025 -0700

    lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC
    
    commit 2b81082ad37cc3f28355fb73a6a69b91ff7dbf20 upstream.
    
    Commit 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with
    clang-17 and older") inadvertently disabled KASAN in curve25519-hacl64.o
    for GCC unconditionally because clang-min-version will always evaluate
    to nothing for GCC. Add a check for CONFIG_CC_IS_CLANG to avoid applying
    the workaround for GCC, which is only needed for clang-17 and older.
    
    Cc: stable@vger.kernel.org
    Fixes: 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Link: https://lore.kernel.org/r/20251103-curve25519-hacl64-fix-kasan-workaround-v2-1-ab581cbd8035@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6828f769d9c91fe65b3dddd328a50a30be889011
Author: Zilin Guan <zilin@seu.edu.cn>
Date:   Thu Nov 6 12:01:32 2025 +0000

    tracing: Fix memory leaks in create_field_var()
    
    [ Upstream commit 80f0d631dcc76ee1b7755bfca1d8417d91d71414 ]
    
    The function create_field_var() allocates memory for 'val' through
    create_hist_field() inside parse_atom(), and for 'var' through
    create_var(), which in turn allocates var->type and var->var.name
    internally. Simply calling kfree() to release these structures will
    result in memory leaks.
    
    Use destroy_hist_field() to properly free 'val', and explicitly release
    the memory of var->type and var->var.name before freeing 'var' itself.
    
    Link: https://patch.msgid.link/20251106120132.3639920-1-zilin@seu.edu.cn
    Fixes: 02205a6752f22 ("tracing: Add support for 'field variables'")
    Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0aabccdcec1f4a36f95829ea2263f845bbc77223
Author: Qendrim Maxhuni <qendrim.maxhuni@garderos.com>
Date:   Wed Oct 29 08:57:44 2025 +0100

    net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup
    
    [ Upstream commit e120f46768d98151ece8756ebd688b0e43dc8b29 ]
    
    Raw IP packets have no MAC header, leaving skb->mac_header uninitialized.
    This can trigger kernel panics on ARM64 when xfrm or other subsystems
    access the offset due to strict alignment checks.
    
    Initialize the MAC header to prevent such crashes.
    
    This can trigger kernel panics on ARM when running IPsec over the
    qmimux0 interface.
    
    Example trace:
    
        Internal error: Oops: 000000009600004f [#1] SMP
        CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
        Hardware name: LS1028A RDB Board (DT)
        pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        pc : xfrm_input+0xde8/0x1318
        lr : xfrm_input+0x61c/0x1318
        sp : ffff800080003b20
        Call trace:
         xfrm_input+0xde8/0x1318
         xfrm6_rcv+0x38/0x44
         xfrm6_esp_rcv+0x48/0xa8
         ip6_protocol_deliver_rcu+0x94/0x4b0
         ip6_input_finish+0x44/0x70
         ip6_input+0x44/0xc0
         ipv6_rcv+0x6c/0x114
         __netif_receive_skb_one_core+0x5c/0x8c
         __netif_receive_skb+0x18/0x60
         process_backlog+0x78/0x17c
         __napi_poll+0x38/0x180
         net_rx_action+0x168/0x2f0
    
    Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
    Signed-off-by: Qendrim Maxhuni <qendrim.maxhuni@garderos.com>
    Link: https://patch.msgid.link/20251029075744.105113-1-qendrim.maxhuni@garderos.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d585109d153a8a624f9504436a3c73494fe97c0
Author: Stefan Wiehler <stefan.wiehler@nokia.com>
Date:   Tue Oct 28 17:12:28 2025 +0100

    sctp: Hold sock lock while iterating over address list
    
    [ Upstream commit f1fc201148c7e684c10a72b6a3375597f28d1ef6 ]
    
    Move address list traversal in inet_assoc_attr_size() under the sock
    lock to avoid holding the RCU read lock.
    
    Suggested-by: Xin Long <lucien.xin@gmail.com>
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Link: https://patch.msgid.link/20251028161506.3294376-4-stefan.wiehler@nokia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80af0466a9e6713522e849c007e410e6cf5b2941
Author: Xin Long <lucien.xin@gmail.com>
Date:   Fri Dec 31 18:37:37 2021 -0500

    sctp: hold endpoint before calling cb in sctp_transport_lookup_process
    
    [ Upstream commit f9d31c4cf4c11ff10317f038b9c6f7c3bda6cdd4 ]
    
    The same fix in commit 5ec7d18d1813 ("sctp: use call_rcu to free endpoint")
    is also needed for dumping one asoc and sock after the lookup.
    
    Fixes: 86fdb3448cc1 ("sctp: ensure ep is not destroyed before doing the dump")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: f1fc201148c7 ("sctp: Hold sock lock while iterating over address list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0dd049bd67acefecf2bad7bd70c2609d1687ecd
Author: Yajun Deng <yajun.deng@linux.dev>
Date:   Tue Jul 13 10:48:24 2021 +0800

    net: Use nlmsg_unicast() instead of netlink_unicast()
    
    [ Upstream commit 01757f536ac825e3614d583fee9acb48c64ed084 ]
    
    It has 'if (err >0 )' statement in nlmsg_unicast(), so use nlmsg_unicast()
    instead of netlink_unicast(), this looks more concise.
    
    v2: remove the change in netfilter.
    
    Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: f1fc201148c7 ("sctp: Hold sock lock while iterating over address list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e047eb027116dd4c237ca6c51fe7e04d1e2beb79
Author: Lu Wei <luwei32@huawei.com>
Date:   Sat Mar 27 10:27:23 2021 +0800

    net: sctp: Fix some typos
    
    [ Upstream commit 21c00a186fac6e035eef5e6751f1e2d2609f969c ]
    
    Modify "unkown" to "unknown" in net/sctp/sm_make_chunk.c and
    Modify "orginal" to "original" in net/sctp/socket.c.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Lu Wei <luwei32@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: f1fc201148c7 ("sctp: Hold sock lock while iterating over address list")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3006959371007fc2eae4a078f823c680fa52de1a
Author: Stefan Wiehler <stefan.wiehler@nokia.com>
Date:   Tue Oct 28 17:12:27 2025 +0100

    sctp: Prevent TOCTOU out-of-bounds write
    
    [ Upstream commit 95aef86ab231f047bb8085c70666059b58f53c09 ]
    
    For the following path not holding the sock lock,
    
      sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()
    
    make sure not to exceed bounds in case the address list has grown
    between buffer allocation (time-of-check) and write (time-of-use).
    
    Suggested-by: Kuniyuki Iwashima <kuniyu@google.com>
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Link: https://patch.msgid.link/20251028161506.3294376-3-stefan.wiehler@nokia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01eaa343081ac62f263953509f1a01a4f72cf82a
Author: Stefan Wiehler <stefan.wiehler@nokia.com>
Date:   Tue Oct 28 17:12:26 2025 +0100

    sctp: Hold RCU read lock while iterating over address list
    
    [ Upstream commit 38f50242bf0f237cdc262308d624d333286ec3c5 ]
    
    With CONFIG_PROVE_RCU_LIST=y and by executing
    
      $ netcat -l --sctp &
      $ netcat --sctp localhost &
      $ ss --sctp
    
    one can trigger the following Lockdep-RCU splat(s):
    
      WARNING: suspicious RCU usage
      6.18.0-rc1-00093-g7f864458e9a6 #5 Not tainted
      -----------------------------
      net/sctp/diag.c:76 RCU-list traversed in non-reader section!!
    
      other info that might help us debug this:
    
      rcu_scheduler_active = 2, debug_locks = 1
      2 locks held by ss/215:
       #0: ffff9c740828bec0 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{4:4}, at: __netlink_dump_start+0x84/0x2b0
       #1: ffff9c7401d72cd0 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_sock_dump+0x38/0x200
    
      stack backtrace:
      CPU: 0 UID: 0 PID: 215 Comm: ss Not tainted 6.18.0-rc1-00093-g7f864458e9a6 #5 PREEMPT(voluntary)
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x5d/0x90
       lockdep_rcu_suspicious.cold+0x4e/0xa3
       inet_sctp_diag_fill.isra.0+0x4b1/0x5d0
       sctp_sock_dump+0x131/0x200
       sctp_transport_traverse_process+0x170/0x1b0
       ? __pfx_sctp_sock_filter+0x10/0x10
       ? __pfx_sctp_sock_dump+0x10/0x10
       sctp_diag_dump+0x103/0x140
       __inet_diag_dump+0x70/0xb0
       netlink_dump+0x148/0x490
       __netlink_dump_start+0x1f3/0x2b0
       inet_diag_handler_cmd+0xcd/0x100
       ? __pfx_inet_diag_dump_start+0x10/0x10
       ? __pfx_inet_diag_dump+0x10/0x10
       ? __pfx_inet_diag_dump_done+0x10/0x10
       sock_diag_rcv_msg+0x18e/0x320
       ? __pfx_sock_diag_rcv_msg+0x10/0x10
       netlink_rcv_skb+0x4d/0x100
       netlink_unicast+0x1d7/0x2b0
       netlink_sendmsg+0x203/0x450
       ____sys_sendmsg+0x30c/0x340
       ___sys_sendmsg+0x94/0xf0
       __sys_sendmsg+0x83/0xf0
       do_syscall_64+0xbb/0x390
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
       ...
       </TASK>
    
    Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
    Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
    Acked-by: Xin Long <lucien.xin@gmail.com>
    Link: https://patch.msgid.link/20251028161506.3294376-2-stefan.wiehler@nokia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed58e1518d8750259cf5464840f29695d29d8f3a
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Sun Nov 2 11:07:57 2025 +0100

    net: dsa: b53: stop reading ARL entries if search is done
    
    [ Upstream commit 0be04b5fa62a82a9929ca261f6c9f64a3d0a28da ]
    
    The switch clears the ARL_SRCH_STDN bit when the search is done, i.e. it
    finished traversing the ARL table.
    
    This means that there will be no valid result, so we should not attempt
    to read and process any further entries.
    
    We only ever check the validity of the entries for 4 ARL bin chips, and
    only after having passed the first entry to the b53_fdb_copy().
    
    This means that we always pass an invalid entry at the end to the
    b53_fdb_copy(). b53_fdb_copy() does check the validity though before
    passing on the entry, so it never gets passed on.
    
    On < 4 ARL bin chips, we will even continue reading invalid entries
    until we reach the result limit.
    
    Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations")
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://patch.msgid.link/20251102100758.28352-3-jonas.gorski@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92a720e2bf563fecbb0120ccbf1eace7a7979120
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Sun Nov 2 11:07:56 2025 +0100

    net: dsa: b53: fix enabling ip multicast
    
    [ Upstream commit c264294624e956a967a9e2e5fa41e3273340b089 ]
    
    In the New Control register bit 1 is either reserved, or has a different
    function:
    
        Out of Range Error Discard
    
        When enabled, the ingress port discards any frames
        if the Length field is between 1500 and 1536
        (excluding 1500 and 1536) and with good CRC.
    
    The actual bit for enabling IP multicast is bit 0, which was only
    explicitly enabled for BCM5325 so far.
    
    For older switch chips, this bit defaults to 0, so we want to enable it
    as well, while newer switch chips default to 1, and their documentation
    says "It is illegal to set this bit to zero."
    
    So drop the wrong B53_IPMC_FWD_EN define, enable the IP multicast bit
    also for other switch chips. While at it, rename it to (B53_)IP_MC as
    that is how it is called in Broadcom code.
    
    Fixes: 63cc54a6f073 ("net: dsa: b53: Fix egress flooding settings")
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://patch.msgid.link/20251102100758.28352-2-jonas.gorski@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89809c7f713a8e84944f3a4fc42b778ad5306aaf
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Sat Nov 1 14:28:06 2025 +0100

    net: dsa: b53: fix resetting speed and pause on forced link
    
    [ Upstream commit b6a8a5477fe9bd6be2b594a88f82f8bba41e6d54 ]
    
    There is no guarantee that the port state override registers have their
    default values, as not all switches support being reset via register or
    have a reset GPIO.
    
    So when forcing port config, we need to make sure to clear all fields,
    which we currently do not do for the speed and flow control
    configuration. This can cause flow control stay enabled, or in the case
    of speed becoming an illegal value, e.g. configured for 1G (0x2), then
    setting 100M (0x1), results in 0x3 which is invalid.
    
    For PORT_OVERRIDE_SPEED_2000M we need to make sure to only clear it on
    supported chips, as the bit can have different meanings on other chips,
    e.g. for BCM5389 this controls scanning PHYs for link/speed
    configuration.
    
    Fixes: 5e004460f874 ("net: dsa: b53: Add helper to set link parameters")
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://patch.msgid.link/20251101132807.50419-2-jonas.gorski@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b934702abd2e64b13868fe77970e13d70195adff
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Oct 30 07:35:39 2025 +0000

    net: vlan: sync VLAN features with lower device
    
    [ Upstream commit c211f5d7cbd5cb34489d526648bb9c8ecc907dee ]
    
    After registering a VLAN device and setting its feature flags, we need to
    synchronize the VLAN features with the lower device. For example, the VLAN
    device does not have the NETIF_F_LRO flag, it should be synchronized with
    the lower device based on the NETIF_F_UPPER_DISABLES definition.
    
    As the dev->vlan_features has changed, we need to call
    netdev_update_features(). The caller must run after netdev_upper_dev_link()
    links the lower devices, so this patch adds the netdev_update_features()
    call in register_vlan_dev().
    
    Fixes: fd867d51f889 ("net/core: generic support for disabling netdev features down stack")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Link: https://patch.msgid.link/20251030073539.133779-1-liuhangbin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b33ff1640e4ccb640cb6e9d1cdd36bcbb1761ec7
Author: Josephine Pfeiffer <hi@josie.lol>
Date:   Mon Oct 27 11:40:43 2025 -0600

    riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro
    
    [ Upstream commit a74f038fa50e0d33b740f44f862fe856f16de6a8 ]
    
    The pt_dump_seq_puts() macro incorrectly uses seq_printf() instead of
    seq_puts(). This is both a performance issue and conceptually wrong,
    as the macro name suggests plain string output (puts) but the
    implementation uses formatted output (printf).
    
    The macro is used in ptdump.c:301 to output a newline character. Using
    seq_printf() adds unnecessary overhead for format string parsing when
    outputting this constant string.
    
    This bug was introduced in commit 59c4da8640cc ("riscv: Add support to
    dump the kernel page tables") in 2020, which copied the implementation
    pattern from other architectures that had the same bug.
    
    Fixes: 59c4da8640cc ("riscv: Add support to dump the kernel page tables")
    Signed-off-by: Josephine Pfeiffer <hi@josie.lol>
    Link: https://lore.kernel.org/r/20251018170451.3355496-1-hi@josie.lol
    Signed-off-by: Paul Walmsley <pjw@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 640c2eeec1178e628a63ebbe5bf997052733e87c
Author: Kailang Yang <kailang@realtek.com>
Date:   Tue Aug 19 14:03:44 2025 +0800

    ALSA: hda/realtek: Audio disappears on HP 15-fc000 after warm boot again
    
    [ Upstream commit f4b3cef55f5f96fdb4e7f9ca90b7d6213689faeb ]
    
    There was a similar bug in the past (Bug 217440), which was fixed for
    this laptop.
    The same issue is occurring again as of kernel v.6.12.2. The symptoms
    are very similar - initially audio works but after a warm reboot, the
    audio completely disappears until the computer is powered off (there
    is no audio output at all).
    
    The issue is also related by caused by a different change now. By
    bisecting different kernel versions, I found that reverting
    cc3d0b5dd989 in patch_realtek.c[*] restores the sound and it works
    fine after the reboot.
    
    [*] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/pci/hda/patch_realtek.c?h=v6.12.2&id=4ed7f16070a8475c088ff423b2eb11ba15eb89b6
    
    [ patch description reformatted by tiwai ]
    
    Fixes: cc3d0b5dd989 ("ALSA: hda/realtek: Update ALC256 depop procedure")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=220109
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Link: https://lore.kernel.org/5317ca723c82447a938414fcca85cbf5@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7279be81955b137e65273da44a43424db595aded
Author: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Date:   Fri Jun 6 12:04:32 2025 -0700

    ceph: add checking of wait_for_completion_killable() return value
    
    [ Upstream commit b7ed1e29cfe773d648ca09895b92856bd3a2092d ]
    
    The Coverity Scan service has detected the calling of
    wait_for_completion_killable() without checking the return
    value in ceph_lock_wait_for_completion() [1]. The CID 1636232
    defect contains explanation: "If the function returns an error
    value, the error value may be mistaken for a normal value.
    In ceph_lock_wait_for_completion(): Value returned from
    a function is not checked for errors before being used. (CWE-252)".
    
    The patch adds the checking of wait_for_completion_killable()
    return value and return the error code from
    ceph_lock_wait_for_completion().
    
    [1] https://scan5.scan.coverity.com/#/project-view/64304/10063?selectedIssue=1636232
    
    Signed-off-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
    Reviewed-by: Alex Markuze <amarkuze@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e2d432099361b03b2fa1a20b764cfbb7f048d31
Author: Valerio Setti <vsetti@baylibre.com>
Date:   Tue Oct 7 00:12:19 2025 +0200

    ASoC: meson: aiu-encoder-i2s: fix bit clock polarity
    
    [ Upstream commit 4c4ed5e073a923fb3323022e1131cb51ad8df7a0 ]
    
    According to I2S specs audio data is sampled on the rising edge of the
    clock and it can change on the falling one. When operating in normal mode
    this SoC behaves the opposite so a clock polarity inversion is required
    in this case.
    
    This was tested on an OdroidC2 (Amlogic S905 SoC) board.
    
    Signed-off-by: Valerio Setti <vsetti@baylibre.com>
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Tested-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://patch.msgid.link/20251007-fix-i2s-polarity-v1-1-86704d9cda10@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0982400648a3e00580253e0c48e991f34d2684c
Author: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Date:   Fri Oct 3 03:32:09 2025 -0400

    fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds
    
    [ Upstream commit 3637d34b35b287ab830e66048841ace404382b67 ]
    
    Add bounds checking to prevent writes past framebuffer boundaries when
    rendering text near screen edges. Return early if the Y position is off-screen
    and clip image height to screen boundary. Break from the rendering loop if the
    X position is off-screen. When clipping image width to fit the screen, update
    the character count to match the clipped width to prevent buffer size
    mismatches.
    
    Without the character count update, bit_putcs_aligned and bit_putcs_unaligned
    receive mismatched parameters where the buffer is allocated for the clipped
    width but cnt reflects the original larger count, causing out-of-bounds writes.
    
    Reported-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190
    Suggested-by: Helge Deller <deller@gmx.de>
    Tested-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
    Signed-off-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f169c59a733722202aade29465b06fdc772f747
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Wed Oct 1 13:26:36 2025 +0300

    ACPI: property: Return present device nodes only on fwnode interface
    
    [ Upstream commit d9f866b2bb3eec38b3734f1fed325ec7c55ccdfa ]
    
    fwnode_graph_get_next_subnode() may return fwnode backed by ACPI
    device nodes and there has been no check these devices are present
    in the system, unlike there has been on fwnode OF backend.
    
    In order to provide consistent behaviour towards callers,
    add a check for device presence by introducing
    a new function acpi_get_next_present_subnode(), used as the
    get_next_child_node() fwnode operation that also checks device
    node presence.
    
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
    Link: https://patch.msgid.link/20251001102636.1272722-2-sakari.ailus@linux.intel.com
    [ rjw: Kerneldoc comment and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9626d90ffc80e2bc3057e8b17ddd502c224323ce
Author: Randall P. Embry <rpembry@gmail.com>
Date:   Fri Sep 26 18:27:31 2025 +0900

    9p: sysfs_init: don't hardcode error to ENOMEM
    
    [ Upstream commit 528f218b31aac4bbfc58914d43766a22ab545d48 ]
    
    v9fs_sysfs_init() always returned -ENOMEM on failure;
    return the actual sysfs_create_group() error instead.
    
    Signed-off-by: Randall P. Embry <rpembry@gmail.com>
    Message-ID: <20250926-v9fs_misc-v1-3-a8b3907fc04d@codewreck.org>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c1861c6115625e1dad1ee3e485ccda8170f227f
Author: Randall P. Embry <rpembry@gmail.com>
Date:   Fri Sep 26 18:27:30 2025 +0900

    9p: fix /sys/fs/9p/caches overwriting itself
    
    [ Upstream commit 86db0c32f16c5538ddb740f54669ace8f3a1f3d7 ]
    
    caches_show() overwrote its buffer on each iteration,
    so only the last cache tag was visible in sysfs output.
    
    Properly append with snprintf(buf + count, …).
    
    Signed-off-by: Randall P. Embry <rpembry@gmail.com>
    Message-ID: <20250926-v9fs_misc-v1-2-a8b3907fc04d@codewreck.org>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5627837cceac08b0c7d7d491ff43f707dbd6f08
Author: Nicolas Ferre <nicolas.ferre@microchip.com>
Date:   Wed Aug 27 16:54:27 2025 +0200

    ARM: at91: pm: save and restore ACR during PLL disable/enable
    
    [ Upstream commit 0c01fe49651d387776abed6a28541e80c8a93319 ]
    
    Add a new word in assembly to store ACR value during the calls
    to at91_plla_disable/at91_plla_enable macros and use it.
    
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    [cristian.birsan@microchip.com: remove ACR_DEFAULT_PLLA loading]
    Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
    Link: https://lore.kernel.org/r/20250827145427.46819-4-nicolas.ferre@microchip.com
    Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb0e5009197af6d71adcc889f8477cb2a902cb9b
Author: Tiwei Bie <tiwei.btw@antgroup.com>
Date:   Wed Aug 27 08:56:59 2025 +0800

    um: Fix help message for ssl-non-raw
    
    [ Upstream commit 725e9d81868fcedaeef775948e699955b01631ae ]
    
    Add the missing option name in the help message. Additionally,
    switch to __uml_help(), because this is a global option rather
    than a per-channel option.
    
    Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91f62370910fd870a5f13f4deaedaf8ad2f97b9c
Author: Yikang Yue <yikangy2@illinois.edu>
Date:   Sat May 3 20:44:34 2025 -0500

    fs/hpfs: Fix error code for new_inode() failure in mkdir/create/mknod/symlink
    
    [ Upstream commit 32058c38d3b79a28963a59ac0353644dc24775cd ]
    
    The function call new_inode() is a primitive for allocating an inode in memory,
    rather than planning disk space for it. Therefore, -ENOMEM should be returned
    as the error code rather than -ENOSPC.
    
    To be specific, new_inode()'s call path looks like this:
    new_inode
      new_inode_pseudo
        alloc_inode
          ops->alloc_inode (hpfs_alloc_inode)
            alloc_inode_sb
              kmem_cache_alloc_lru
    
    Therefore, the failure of new_inode() indicates a memory presure issue (-ENOMEM),
    not a lack of disk space. However, the current implementation of
    hpfs_mkdir/create/mknod/symlink incorrectly returns -ENOSPC when new_inode() fails.
    This patch fix this by set err to -ENOMEM before the goto statement.
    
    BTW, we also noticed that other nested calls within these four functions,
    like hpfs_alloc_f/dnode and hpfs_add_dirent, might also fail due to memory presure.
    But similarly, only -ENOSPC is returned. Addressing these will involve code
    modifications in other functions, and we plan to submit dedicated patches for these
    issues in the future. For this patch, we focus on new_inode().
    
    Signed-off-by: Yikang Yue <yikangy2@illinois.edu>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c88c7850f92e2702fccb5e83498b197463696e1a
Author: austinchang <austinchang@synology.com>
Date:   Wed Oct 29 09:35:27 2025 +0000

    btrfs: mark dirty extent range for out of bound prealloc extents
    
    [ Upstream commit 3b1a4a59a2086badab391687a6a0b86e03048393 ]
    
    In btrfs_fallocate(), when the allocated range overlaps with a prealloc
    extent and the extent starts after i_size, the range doesn't get marked
    dirty in file_extent_tree. This results in persisting an incorrect
    disk_i_size for the inode when not using the no-holes feature.
    
    This is reproducible since commit 41a2ee75aab0 ("btrfs: introduce
    per-inode file extent tree"), then became hidden since commit 3d7db6e8bd22
    ("btrfs: don't allocate file extent tree for non regular files") and then
    visible again after commit 8679d2687c35 ("btrfs: initialize
    inode::file_extent_tree after i_mode has been set"), which fixes the
    previous commit.
    
    The following reproducer triggers the problem:
    
    $ cat test.sh
    
    MNT=/mnt/test
    DEV=/dev/vdb
    
    mkdir -p $MNT
    
    mkfs.btrfs -f -O ^no-holes $DEV
    mount $DEV $MNT
    
    touch $MNT/file1
    fallocate -n -o 1M -l 2M $MNT/file1
    
    umount $MNT
    mount $DEV $MNT
    
    len=$((1 * 1024 * 1024))
    
    fallocate -o 1M -l $len $MNT/file1
    
    du --bytes $MNT/file1
    
    umount $MNT
    mount $DEV $MNT
    
    du --bytes $MNT/file1
    
    umount $MNT
    
    Running the reproducer gives the following result:
    
    $ ./test.sh
    (...)
    2097152 /mnt/test/file1
    1048576 /mnt/test/file1
    
    The difference is exactly 1048576 as we assigned.
    
    Fix by adding a call to btrfs_inode_set_file_extent_range() in
    btrfs_fallocate_update_isize().
    
    Fixes: 41a2ee75aab0 ("btrfs: introduce per-inode file extent tree")
    Signed-off-by: austinchang <austinchang@synology.com>
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bbe93d5ac5a78c430edba8bfaf3be3852d7ac73
Author: Saket Dumbre <saket.dumbre@intel.com>
Date:   Fri Sep 12 22:01:04 2025 +0200

    ACPICA: Update dsmethod.c to get rid of unused variable warning
    
    [ Upstream commit 761dc71c6020d6aa68666e96373342d49a7e9d0a ]
    
    All the 3 major C compilers (MSVC, GCC, LLVM/Clang) warn about
    the unused variable i after the removal of its usage by PR #1031
    addressing Issue #1027
    
    Link: https://github.com/acpica/acpica/commit/6d235320
    Signed-off-by: Saket Dumbre <saket.dumbre@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef892d2bf4f3fa2c8de1677dd307e678bdd3d865
Author: Mike Marshall <hubcap@omnibond.com>
Date:   Mon Sep 15 17:40:46 2025 -0400

    orangefs: fix xattr related buffer overflow...
    
    [ Upstream commit 025e880759c279ec64d0f754fe65bf45961da864 ]
    
    Willy Tarreau <w@1wt.eu> forwarded me a message from
    Disclosure <disclosure@aisle.com> with the following
    warning:
    
    > The helper `xattr_key()` uses the pointer variable in the loop condition
    > rather than dereferencing it. As `key` is incremented, it remains non-NULL
    > (until it runs into unmapped memory), so the loop does not terminate on
    > valid C strings and will walk memory indefinitely, consuming CPU or hanging
    > the thread.
    
    I easily reproduced this with setfattr and getfattr, causing a kernel
    oops, hung user processes and corrupted orangefs files. Disclosure
    sent along a diff (not a patch) with a suggested fix, which I based
    this patch on.
    
    After xattr_key started working right, xfstest generic/069 exposed an
    xattr related memory leak that lead to OOM. xattr_key returns
    a hashed key.  When adding xattrs to the orangefs xattr cache, orangefs
    used hash_add, a kernel hashing macro. hash_add also hashes the key using
    hash_log which resulted in additions to the xattr cache going to the wrong
    hash bucket. generic/069 tortures a single file and orangefs does a
    getattr for the xattr "security.capability" every time. Orangefs
    negative caches on xattrs which includes a kmalloc. Since adds to the
    xattr cache were going to the wrong bucket, every getattr for
    "security.capability" resulted in another kmalloc, none of which were
    ever freed.
    
    I changed the two uses of hash_add to hlist_add_head instead
    and the memory leak ceased and generic/069 quit throwing furniture.
    
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Reported-by: Stanislav Fort of Aisle Research <stanislav.fort@aisle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 79698f5d4e9de3605e5aeb6389f58298e435dcaf
Author: Dragos Tatulea <dtatulea@nvidia.com>
Date:   Fri Sep 26 16:16:05 2025 +0300

    page_pool: Clamp pool size to max 16K pages
    
    [ Upstream commit a1b501a8c6a87c9265fd03bd004035199e2e8128 ]
    
    page_pool_init() returns E2BIG when the page_pool size goes above 32K
    pages. As some drivers are configuring the page_pool size according to
    the MTU and ring size, there are cases where this limit is exceeded and
    the queue creation fails.
    
    The page_pool size doesn't have to cover a full queue, especially for
    larger ring size. So clamp the size instead of returning an error. Do
    this in the core to avoid having each driver do the clamping.
    
    The current limit was deemed to high [1] so it was reduced to 16K to avoid
    page waste.
    
    [1] https://lore.kernel.org/all/1758532715-820422-3-git-send-email-tariqt@nvidia.com/
    
    Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://patch.msgid.link/20250926131605.2276734-2-dtatulea@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df7633745a97a1e2c869105a10ec5ecb9058ae1c
Author: Chi Zhiling <chizhiling@kylinos.cn>
Date:   Fri Aug 15 17:32:45 2025 +0800

    exfat: limit log print for IO error
    
    [ Upstream commit 6dfba108387bf4e71411b3da90b2d5cce48ba054 ]
    
    For exFAT filesystems with 4MB read_ahead_size, removing the storage device
    when the read operation is in progress, which cause the last read syscall
    spent 150s [1]. The main reason is that exFAT generates excessive log
    messages [2].
    
    After applying this patch, approximately 300,000 lines of log messages
    were suppressed, and the delay of the last read() syscall was reduced
    to about 4 seconds.
    
    [1]:
    write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000120>
    read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000032>
    write(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 <0.000119>
    read(4, 0x7fccf28ae000, 131072)         = -1 EIO (Input/output error) <150.186215>
    
    [2]:
    [  333.696603] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5)
    [  333.697378] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5)
    [  333.698156] exFAT-fs (vdb): error, failed to access to FAT (entry 0x0000d780, err:-5)
    
    Signed-off-by: Chi Zhiling <chizhiling@kylinos.cn>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbc9798503decac3b5e219498b2753a7a5b285c0
Author: Roy Vegard Ovesen <roy.vegard.ovesen@gmail.com>
Date:   Sat Sep 27 17:27:30 2025 +0200

    ALSA: usb-audio: add mono main switch to Presonus S1824c
    
    [ Upstream commit 659169c4eb21f8d9646044a4f4e1bc314f6f9d0c ]
    
    The 1824c does not have the A/B switch that the 1810c has,
    but instead it has a mono main switch that sums the two
    main output channels to mono.
    
    Signed-off-by: Roy Vegard Ovesen <roy.vegard.ovesen@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 164586725b47f9d61912e6bf17dbaffeff11710b
Author: Ivan Pravdin <ipravdin.official@gmail.com>
Date:   Sat Aug 30 16:03:40 2025 -0400

    Bluetooth: bcsp: receive data only if registered
    
    [ Upstream commit ca94b2b036c22556c3a66f1b80f490882deef7a6 ]
    
    Currently, bcsp_recv() can be called even when the BCSP protocol has not
    been registered. This leads to a NULL pointer dereference, as shown in
    the following stack trace:
    
        KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]
        RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
        Call Trace:
         <TASK>
         hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
         tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
         tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
         vfs_ioctl fs/ioctl.c:51 [inline]
         __do_sys_ioctl fs/ioctl.c:907 [inline]
         __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
         do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
         do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
         entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    To prevent this, ensure that the HCI_UART_REGISTERED flag is set before
    processing received data. If the protocol is not registered, return
    -EUNATCH.
    
    Reported-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=4ed6852d4da4606c93da
    Tested-by: syzbot+4ed6852d4da4606c93da@syzkaller.appspotmail.com
    Signed-off-by: Ivan Pravdin <ipravdin.official@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c17caff1062ca91ebac44bfd01d2fb3d99dc0e23
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Sep 22 13:13:13 2025 -0400

    Bluetooth: SCO: Fix UAF on sco_conn_free
    
    [ Upstream commit ecb9a843be4d6fd710d7026e359f21015a062572 ]
    
    BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]
    BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]
    BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410
    net/bluetooth/sco.c:107
    Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352
    
    CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted
    6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    Workqueue: hci13 hci_cmd_sync_work
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:378 [inline]
     print_report+0x191/0x550 mm/kasan/report.c:482
     kasan_report+0xc4/0x100 mm/kasan/report.c:595
     sco_conn_free net/bluetooth/sco.c:87 [inline]
     kref_put include/linux/kref.h:65 [inline]
     sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107
     sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441
     hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline]
     hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313
     hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121
     hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147
     hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689
     hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332
     process_one_work kernel/workqueue.c:3236 [inline]
     process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319
     worker_thread+0xbee/0x1200 kernel/workqueue.c:3400
     kthread+0x3c7/0x870 kernel/kthread.c:463
     ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
     </TASK>
    
    Allocated by task 31370:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x30/0x70 mm/kasan/common.c:68
     poison_kmalloc_redzone mm/kasan/common.c:388 [inline]
     __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405
     kasan_kmalloc include/linux/kasan.h:260 [inline]
     __do_kmalloc_node mm/slub.c:4382 [inline]
     __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394
     kmalloc_noprof include/linux/slab.h:909 [inline]
     sk_prot_alloc+0xae/0x220 net/core/sock.c:2239
     sk_alloc+0x34/0x5a0 net/core/sock.c:2295
     bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151
     sco_sock_alloc net/bluetooth/sco.c:562 [inline]
     sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593
     bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135
     __sock_create+0x3ad/0x780 net/socket.c:1589
     sock_create net/socket.c:1647 [inline]
     __sys_socket_create net/socket.c:1684 [inline]
     __sys_socket+0xd5/0x330 net/socket.c:1731
     __do_sys_socket net/socket.c:1745 [inline]
     __se_sys_socket net/socket.c:1743 [inline]
     __x64_sys_socket+0x7a/0x90 net/socket.c:1743
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Freed by task 31374:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x30/0x70 mm/kasan/common.c:68
     kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576
     poison_slab_object mm/kasan/common.c:243 [inline]
     __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275
     kasan_slab_free include/linux/kasan.h:233 [inline]
     slab_free_hook mm/slub.c:2428 [inline]
     slab_free mm/slub.c:4701 [inline]
     kfree+0x199/0x3b0 mm/slub.c:4900
     sk_prot_free net/core/sock.c:2278 [inline]
     __sk_destruct+0x4aa/0x630 net/core/sock.c:2373
     sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333
     __sock_release net/socket.c:649 [inline]
     sock_close+0xb8/0x230 net/socket.c:1439
     __fput+0x3d1/0x9e0 fs/file_table.c:468
     task_work_run+0x206/0x2a0 kernel/task_work.c:227
     get_signal+0x1201/0x1410 kernel/signal.c:2807
     arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337
     exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40
     exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]
     syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]
     syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]
     do_syscall_64+0x1dd/0x240 arch/x86/entry/syscall_64.c:100
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Reported-by: cen zhang <zzzccc427@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c6ae60cf0a326e8dc34da2b206b7457b4f29b2a
Author: Théo Lebrun <theo.lebrun@bootlin.com>
Date:   Tue Sep 23 18:00:27 2025 +0200

    net: macb: avoid dealing with endianness in macb_set_hwaddr()
    
    [ Upstream commit 70a5ce8bc94545ba0fb47b2498bfb12de2132f4d ]
    
    bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32
    pointer and dereferencing implies dealing manually with endianness,
    which is error-prone.
    
    Replace by calls to get_unaligned_le32|le16() helpers.
    
    This was found using sparse:
       ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o
       warning: incorrect type in assignment (different base types)
          expected unsigned int [usertype] bottom
          got restricted __le32 [usertype]
       warning: incorrect type in assignment (different base types)
          expected unsigned short [usertype] top
          got restricted __le16 [usertype]
       ...
    
    Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
    Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250923-macb-fixes-v6-5-772d655cdeb6@bootlin.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e6b27f4e68682aa3db9f83ca04adef89903159b
Author: chuguangqing <chuguangqing@inspur.com>
Date:   Wed Aug 6 10:28:49 2025 +0800

    fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock
    
    [ Upstream commit 1534f72dc2a11ded38b0e0268fbcc0ca24e9fd4a ]
    
    The parent function ext4_xattr_inode_lookup_create already uses GFP_NOFS for memory alloction, so the function ext4_xattr_inode_cache_find should use same gfp_flag.
    
    Signed-off-by: chuguangqing <chuguangqing@inspur.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6cafe71eb3b5579b245ba1bd528a181e77f3df1
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Tue Sep 16 17:22:45 2025 +0100

    nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
    
    [ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ]
    
    Theoretically it's an oopsable race, but I don't believe one can manage
    to hit it on real hardware; might become doable on a KVM, but it still
    won't be easy to attack.
    
    Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of
    put_unaligned_be64(), we can put that under ->d_lock and be done with that.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6c3f8cad39de45130f123e3e0df85f1d0b772f6
Author: Anthony Iliopoulos <ailiop@suse.com>
Date:   Wed Aug 13 11:00:47 2025 +0200

    NFSv4.1: fix mount hang after CREATE_SESSION failure
    
    [ Upstream commit bf75ad096820fee5da40e671ebb32de725a1c417 ]
    
    When client initialization goes through server trunking discovery, it
    schedules the state manager and then sleeps waiting for nfs_client
    initialization completion.
    
    The state manager can fail during state recovery, and specifically in
    lease establishment as nfs41_init_clientid() will bail out in case of
    errors returned from nfs4_proc_create_session(), without ever marking
    the client ready. The session creation can fail for a variety of reasons
    e.g. during backchannel parameter negotiation, with status -EINVAL.
    
    The error status will propagate all the way to the nfs4_state_manager
    but the client status will not be marked, and thus the mount process
    will remain blocked waiting.
    
    Fix it by adding -EINVAL error handling to nfs4_state_manager().
    
    Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
    Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbf21f07d832c5f14545d87514139b687670f4f5
Author: Olga Kornievskaia <okorniev@redhat.com>
Date:   Mon Aug 11 14:18:48 2025 -0400

    NFSv4: handle ERR_GRACE on delegation recalls
    
    [ Upstream commit be390f95242785adbf37d7b8a5101dd2f2ba891b ]
    
    RFC7530 states that clients should be prepared for the return of
    NFS4ERR_GRACE errors for non-reclaim lock and I/O requests.
    
    Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
    Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b99aa828bd7b3bb7e8eac25a9d4a853437a6f6a8
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Aug 20 18:02:34 2025 +0200

    remoteproc: qcom: q6v5: Avoid handling handover twice
    
    [ Upstream commit 54898664e1eb6b5b3e6cdd9343c6eb15da776153 ]
    
    A remoteproc could theoretically signal handover twice. This is unexpected
    and would break the reference counting for the handover resources (power
    domains, clocks, regulators, etc), so add a check to prevent that from
    happening.
    
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Link: https://lore.kernel.org/r/20250820-rproc-qcom-q6v5-fixes-v2-2-910b1a3aff71@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ece871e9c513e5a2c4ca0f08757ddb114a28df8
Author: Koakuma <koachan@protonmail.com>
Date:   Mon Jun 9 20:53:11 2025 +0700

    sparc/module: Add R_SPARC_UA64 relocation handling
    
    [ Upstream commit 05457d96175d25c976ab6241c332ae2eb5e07833 ]
    
    This is needed so that the kernel can handle R_SPARC_UA64 relocations,
    which is emitted by LLVM's IAS.
    
    Signed-off-by: Koakuma <koachan@protonmail.com>
    Reviewed-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5dbe92ac8a4ca6226093241f95f9cb1b0d2e0e1
Author: Chen Wang <unicorn_wang@outlook.com>
Date:   Fri Sep 12 10:36:01 2025 +0800

    PCI: cadence: Check for the existence of cdns_pcie::ops before using it
    
    [ Upstream commit 49a6c160ad4812476f8ae1a8f4ed6d15adfa6c09 ]
    
    cdns_pcie::ops might not be populated by all the Cadence glue drivers. This
    is going to be true for the upcoming Sophgo platform which doesn't set the
    ops.
    
    Hence, add a check to prevent NULL pointer dereference.
    
    Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
    [mani: reworded subject and description]
    Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
    Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bfe3fcca39b0010335c1d3e3cfaa319bb06a51b2
Author: ChunHao Lin <hau@realtek.com>
Date:   Thu Sep 18 10:34:25 2025 +0800

    r8169: set EEE speed down ratio to 1
    
    [ Upstream commit bf7154ffb1c65a201906296a9d3eb22e9daa5ffc ]
    
    EEE speed down means speed down MAC MCU clock. It is not from spec.
    It is kind of Realtek specific power saving feature. But enable it
    may cause some issues, like packet drop or interrupt loss. Different
    hardware may have different issues.
    
    EEE speed down ratio (mac ocp 0xe056[7:4]) is used to set EEE speed
    down rate. The larger this value is, the more power can save. But it
    actually save less power then we expected. And, as mentioned above,
    will impact compatibility. So set it to 1 (mac ocp 0xe056[7:4] = 0)
    , which means not to speed down, to improve compatibility.
    
    Signed-off-by: ChunHao Lin <hau@realtek.com>
    Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://patch.msgid.link/20250918023425.3463-1-hau@realtek.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31ed53d61d4e0e63f8b118911b3894aab4e7b642
Author: Brahmajit Das <listout@listout.xyz>
Date:   Tue Sep 2 12:54:22 2025 +0530

    net: intel: fm10k: Fix parameter idx set but not used
    
    [ Upstream commit 99e9c5ffbbee0f258a1da4eadf602b943f8c8300 ]
    
    Variable idx is set in the loop, but is never used resulting in dead
    code. Building with GCC 16, which enables
    -Werror=unused-but-set-parameter= by default results in build error.
    This patch removes the idx parameter, since all the callers of the
    fm10k_unbind_hw_stats_q as 0 as idx anyways.
    
    Suggested-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
    Signed-off-by: Brahmajit Das <listout@listout.xyz>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9fcd691858f4180ee5fd9b10962c3a3ff3ea0d7
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>
Date:   Tue Sep 2 16:32:25 2025 +0200

    wifi: ath10k: Fix connection after GTK rekeying
    
    [ Upstream commit 487e8a8c3421df0af3707e54c7e069f1d89cbda7 ]
    
    It appears that not all hardware/firmware implementations support
    group key deletion correctly, which can lead to connection hangs
    and deauthentication following GTK rekeying (delete and install).
    
    To avoid this issue, instead of attempting to delete the key using
    the special WMI_CIPHER_NONE value, we now replace the key with an
    invalid (random) value.
    
    This behavior has been observed with WCN39xx chipsets.
    
    Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1
    Reported-by: Alexey Klimov <alexey.klimov@linaro.org>
    Closes: https://lore.kernel.org/all/DAWJQ2NIKY28.1XOG35E4A682G@linaro.org
    Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
    Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
    Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
    Tested-by: Alexey Klimov <alexey.klimov@linaro.org> # QRB2210 RB1
    Link: https://patch.msgid.link/20250902143225.837487-1-loic.poulain@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8cae9cf23e0bd424ac904e753639a587543ce03a
Author: Shaurya Rane <ssrane_b23@ee.vjti.ac.in>
Date:   Mon Aug 25 01:43:32 2025 +0530

    jfs: fix uninitialized waitqueue in transaction manager
    
    [ Upstream commit 300b072df72694ea330c4c673c035253e07827b8 ]
    
    The transaction manager initialization in txInit() was not properly
    initializing TxBlock[0].waitor waitqueue, causing a crash when
    txEnd(0) is called on read-only filesystems.
    
    When a filesystem is mounted read-only, txBegin() returns tid=0 to
    indicate no transaction. However, txEnd(0) still gets called and
    tries to access TxBlock[0].waitor via tid_to_tblock(0), but this
    waitqueue was never initialized because the initialization loop
    started at index 1 instead of 0.
    
    This causes a 'non-static key' lockdep warning and system crash:
      INFO: trying to register non-static key in txEnd
    
    Fix by ensuring all transaction blocks including TxBlock[0] have
    their waitqueues properly initialized during txInit().
    
    Reported-by: syzbot+c4f3462d8b2ad7977bea@syzkaller.appspotmail.com
    
    Signed-off-by: Shaurya Rane <ssrane_b23@ee.vjti.ac.in>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fabc1348bb8fe6bc80850014ee94bd89945f7f4d
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Fri Sep 12 23:18:44 2025 +0900

    jfs: Verify inode mode when loading from disk
    
    [ Upstream commit 7a5aa54fba2bd591b22b9b624e6baa9037276986 ]
    
    The inode mode loaded from corrupted disk can be invalid. Do like what
    commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")
    does.
    
    Reported-by: syzbot <syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9209f889151b6a04ae50b09137008b933ae9892
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Sep 16 16:09:44 2025 +0000

    ipv6: np->rxpmtu race annotation
    
    [ Upstream commit 9fba1eb39e2f74d2002c5cbcf1d4435d37a4f752 ]
    
    Add READ_ONCE() annotations because np->rxpmtu can be changed
    while udpv6_recvmsg() and rawv6_recvmsg() read it.
    
    Since this is a very rarely used feature, and that udpv6_recvmsg()
    and rawv6_recvmsg() read np->rxopt anyway, change the test order
    so that np->rxpmtu does not need to be in a hot cache line.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
    Link: https://patch.msgid.link/20250916160951.541279-4-edumazet@google.com
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9800f77348350fa4394793c5239eb9037b0814ea
Author: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Date:   Tue Sep 16 17:34:36 2025 +0530

    usb: xhci: plat: Facilitate using autosuspend for xhci plat devices
    
    [ Upstream commit 41cf11946b9076383a2222bbf1ef57d64d033f66 ]
    
    Allow autosuspend to be used by xhci plat device. For Qualcomm SoCs,
    when in host mode, it is intended that the controller goes to suspend
    state to save power and wait for interrupts from connected peripheral
    to wake it up. This is particularly used in cases where a HID or Audio
    device is connected. In such scenarios, the usb controller can enter
    auto suspend and resume action after getting interrupts from the
    connected device.
    
    Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250916120436.3617598-1-krishna.kurapati@oss.qualcomm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9442fc6f3de002fef101c1ee2b56fa078c926e1e
Author: Forest Crossman <cyrozap@gmail.com>
Date:   Mon Sep 15 15:55:10 2025 -0400

    usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBs
    
    [ Upstream commit 368ed48a5ef52e384f54d5809f0a0b79ac567479 ]
    
    The usbmon binary interface currently truncates captures of large
    transfers from higher-speed USB devices. Because a single event capture
    is limited to one-fifth of the total buffer size, the current maximum
    size of a captured URB is around 240 KiB. This is insufficient when
    capturing traffic from modern devices that use transfers of several
    hundred kilobytes or more, as truncated URBs can make it impossible for
    user-space USB analysis tools like Wireshark to properly defragment and
    reassemble higher-level protocol packets in the captured data.
    
    The root cause of this issue is the 1200 KiB BUFF_MAX limit, which has
    not been changed since the binary interface was introduced in 2006.
    
    To resolve this issue, this patch increases BUFF_MAX to 64 MiB. The
    original comment for BUFF_MAX based the limit's calculation on a
    saturated 480 Mbit/s bus. Applying the same logic to a modern USB 3.2
    Gen 2×2 20 Gbit/s bus (~2500 MB/s over a 20ms window) indicates the
    buffer should be at least 50 MB. The new limit of 64 MiB covers that,
    plus a little extra for any overhead.
    
    With this change, both users and developers should now be able to debug
    and reverse engineer modern USB devices even when running unmodified
    distro kernels.
    
    Please note that this change does not affect the default buffer size. A
    larger buffer is only allocated when a user explicitly requests it via
    the MON_IOCT_RING_SIZE ioctl, so the change to the maximum buffer size
    should not unduly increase memory usage for users that don't
    deliberately request a larger buffer.
    
    Link: https://lore.kernel.org/CAO3ALPzdUkmMr0YMrODLeDSLZqNCkWcAP8NumuPHLjNJ8wC1kQ@mail.gmail.com
    Signed-off-by: Forest Crossman <cyrozap@gmail.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/CAO3ALPxU5RzcoueC454L=WZ1qGMfAcnxm+T+p+9D8O9mcrUbCQ@mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2fe16c67e2a5bb3742c07403b87ca9a9426efc3
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 12 11:20:27 2025 -0400

    allow finish_no_open(file, ERR_PTR(-E...))
    
    [ Upstream commit fe91e078b60d1beabf5cef4a37c848457a6d2dfb ]
    
    ... allowing any ->lookup() return value to be passed to it.
    
    Reviewed-by: NeilBrown <neil@brown.name>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82a20f33b1f3d2d2c7ead424f93d63c438f401c9
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Mon Sep 15 11:08:05 2025 -0700

    scsi: lpfc: Define size of debugfs entry for xri rebalancing
    
    [ Upstream commit 5de09770b1c0e229d2cec93e7f634fcdc87c9bc8 ]
    
    To assist in debugging lpfc_xri_rebalancing driver parameter, a debugfs
    entry is used.  The debugfs file operations for xri rebalancing have
    been previously implemented, but lack definition for its information
    buffer size.  Similar to other pre-existing debugfs entry buffers,
    define LPFC_HDWQINFO_SIZE as 8192 bytes.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Message-ID: <20250915180811.137530-9-justintee8345@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 490a21e8d0ca1440f271856c48ae6b91882108e4
Author: Nai-Chen Cheng <bleach1827@gmail.com>
Date:   Wed Sep 10 19:30:32 2025 +0800

    selftests/Makefile: include $(INSTALL_DEP_TARGETS) in clean target to clean net/lib dependency
    
    [ Upstream commit d3f7457da7b9527a06dbcbfaf666aa51ac2eeb53 ]
    
    The selftests 'make clean' does not clean the net/lib because it only
    processes $(TARGETS) and ignores $(INSTALL_DEP_TARGETS). This leaves
    compiled objects in net/lib after cleaning, requiring manual cleanup.
    
    Include $(INSTALL_DEP_TARGETS) in clean target to ensure net/lib
    dependency is properly cleaned.
    
    Signed-off-by: Nai-Chen Cheng <bleach1827@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Simon Horman <horms@kernel.org> # build-tested
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://patch.msgid.link/20250910-selftests-makefile-clean-v1-1-29e7f496cd87@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20e4e12af9c2674ae1688092cba9a0cc82e0b1ee
Author: Yafang Shao <laoar.shao@gmail.com>
Date:   Tue Sep 2 14:29:33 2025 +0800

    net/cls_cgroup: Fix task_get_classid() during qdisc run
    
    [ Upstream commit 66048f8b3cc7e462953c04285183cdee43a1cb89 ]
    
    During recent testing with the netem qdisc to inject delays into TCP
    traffic, we observed that our CLS BPF program failed to function correctly
    due to incorrect classid retrieval from task_get_classid(). The issue
    manifests in the following call stack:
    
            bpf_get_cgroup_classid+5
            cls_bpf_classify+507
            __tcf_classify+90
            tcf_classify+217
            __dev_queue_xmit+798
            bond_dev_queue_xmit+43
            __bond_start_xmit+211
            bond_start_xmit+70
            dev_hard_start_xmit+142
            sch_direct_xmit+161
            __qdisc_run+102             <<<<< Issue location
            __dev_xmit_skb+1015
            __dev_queue_xmit+637
            neigh_hh_output+159
            ip_finish_output2+461
            __ip_finish_output+183
            ip_finish_output+41
            ip_output+120
            ip_local_out+94
            __ip_queue_xmit+394
            ip_queue_xmit+21
            __tcp_transmit_skb+2169
            tcp_write_xmit+959
            __tcp_push_pending_frames+55
            tcp_push+264
            tcp_sendmsg_locked+661
            tcp_sendmsg+45
            inet_sendmsg+67
            sock_sendmsg+98
            sock_write_iter+147
            vfs_write+786
            ksys_write+181
            __x64_sys_write+25
            do_syscall_64+56
            entry_SYSCALL_64_after_hwframe+100
    
    The problem occurs when multiple tasks share a single qdisc. In such cases,
    __qdisc_run() may transmit skbs created by different tasks. Consequently,
    task_get_classid() retrieves an incorrect classid since it references the
    current task's context rather than the skb's originating task.
    
    Given that dev_queue_xmit() always executes with bh disabled, we can use
    softirq_count() instead to obtain the correct classid.
    
    The simple steps to reproduce this issue:
    1. Add network delay to the network interface:
      such as: tc qdisc add dev bond0 root netem delay 1.5ms
    2. Build two distinct net_cls cgroups, each with a network-intensive task
    3. Initiate parallel TCP streams from both tasks to external servers.
    
    Under this specific condition, the issue reliably occurs. The kernel
    eventually dequeues an SKB that originated from Task-A while executing in
    the context of Task-B.
    
    It is worth noting that it will change the established behavior for a
    slightly different scenario:
    
      <sock S is created by task A>
      <class ID for task A is changed>
      <skb is created by sock S xmit and classified>
    
    prior to this patch the skb will be classified with the 'new' task A
    classid, now with the old/original one. The bpf_get_cgroup_classid_curr()
    function is a more appropriate choice for this case.
    
    Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Thomas Graf <tgraf@suug.ch>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://patch.msgid.link/20250902062933.30087-1-laoar.shao@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 087f1ed450dc6e7e49ffbbbe5b78be1218c6d5e0
Author: Alok Tiwari <alok.a.tiwari@oracle.com>
Date:   Wed Sep 10 12:50:26 2025 -0700

    udp_tunnel: use netdev_warn() instead of netdev_WARN()
    
    [ Upstream commit dc2f650f7e6857bf384069c1a56b2937a1ee370d ]
    
    netdev_WARN() uses WARN/WARN_ON to print a backtrace along with
    file and line information. In this case, udp_tunnel_nic_register()
    returning an error is just a failed operation, not a kernel bug.
    
    udp_tunnel_nic_register() can fail due to a memory allocation
    failure (kzalloc() or udp_tunnel_nic_alloc()).
    This is a normal runtime error and not a kernel bug.
    
    Replace netdev_WARN() with netdev_warn() accordingly.
    
    Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250910195031.3784748-1-alok.a.tiwari@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 780095c51e34ec7cdf6f651b4c4f2b35680779e4
Author: David Ahern <dsahern@kernel.org>
Date:   Tue Sep 9 20:58:28 2025 -0600

    selftests: Replace sleep with slowwait
    
    [ Upstream commit 2f186dd5585c3afb415df80e52f71af16c9d3655 ]
    
    Replace the sleep in kill_procs with slowwait.
    
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250910025828.38900-2-dsahern@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5e62abccc58be8938b368d15745925d2c06658bc
Author: Daniel Palmer <daniel@thingy.jp>
Date:   Sun Sep 7 15:43:49 2025 +0900

    eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP
    
    [ Upstream commit 43adad382e1fdecabd2c4cd2bea777ef4ce4109e ]
    
    When 8139too is probing and 8139TOO_PIO=y it will call pci_iomap_range()
    and from there __pci_ioport_map() for the PCI IO space.
    If HAS_IOPORT_MAP=n and NO_GENERIC_PCI_IOPORT_MAP=n, like it is on my
    m68k config, __pci_ioport_map() becomes NULL, pci_iomap_range() will
    always fail and the driver will complain it couldn't map the PIO space
    and return an error.
    
    NO_IOPORT_MAP seems to cover the case where what 8139too is trying
    to do cannot ever work so make 8139TOO_PIO depend on being it false
    and avoid creating an unusable driver.
    
    Signed-off-by: Daniel Palmer <daniel@thingy.jp>
    Link: https://patch.msgid.link/20250907064349.3427600-1-daniel@thingy.jp
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44c61c5bba45b4feba3f89a068ebc899ccf05ca7
Author: David Ahern <dsahern@kernel.org>
Date:   Tue Sep 9 20:58:27 2025 -0600

    selftests: Disable dad for ipv6 in fcnal-test.sh
    
    [ Upstream commit 53d591730ea34f97a82f7ec6e7c987ca6e34dc21 ]
    
    Constrained test environment; duplicate address detection is not needed
    and causes races so disable it.
    
    Signed-off-by: David Ahern <dsahern@kernel.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250910025828.38900-1-dsahern@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4ca9106bc34cf6a30d8eeaf297d4af5954506fd8
Author: Li RongQing <lirongqing@baidu.com>
Date:   Tue Jul 22 19:00:05 2025 +0800

    x86/kvm: Prefer native qspinlock for dedicated vCPUs irrespective of PV_UNHALT
    
    [ Upstream commit 960550503965094b0babd7e8c83ec66c8a763b0b ]
    
    The commit b2798ba0b876 ("KVM: X86: Choose qspinlock when dedicated
    physical CPUs are available") states that when PV_DEDICATED=1
    (vCPU has dedicated pCPU), qspinlock should be preferred regardless of
    PV_UNHALT.  However, the current implementation doesn't reflect this: when
    PV_UNHALT=0, we still use virt_spin_lock() even with dedicated pCPUs.
    
    This is suboptimal because:
    1. Native qspinlocks should outperform virt_spin_lock() for dedicated
       vCPUs irrespective of HALT exiting
    2. virt_spin_lock() should only be preferred when vCPUs may be preempted
       (non-dedicated case)
    
    So reorder the PV spinlock checks to:
    1. First handle dedicated pCPU case (disable virt_spin_lock_key)
    2. Second check single CPU, and nopvspin configuration
    3. Only then check PV_UNHALT support
    
    This ensures we always use native qspinlock for dedicated vCPUs, delivering
    pretty performance gains at high contention levels.
    
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Reviewed-by: Sean Christopherson <seanjc@google.com>
    Tested-by: Wangyang Guo <wangyang.guo@intel.com>
    Link: https://lore.kernel.org/r/20250722110005.4988-1-lirongqing@baidu.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b499c6da109f25fa10e359d7bbb529a69be5d41
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Mon Sep 8 10:32:35 2025 +0300

    selftests: traceroute: Use require_command()
    
    [ Upstream commit 47efbac9b768553331b9459743a29861e0acd797 ]
    
    Use require_command() so that the test will return SKIP (4) when a
    required command is not present.
    
    Before:
    
     # ./traceroute.sh
     SKIP: Could not run IPV6 test without traceroute6
     SKIP: Could not run IPV4 test without traceroute
     $ echo $?
     0
    
    After:
    
     # ./traceroute.sh
     TEST: traceroute6 not installed                                    [SKIP]
     $ echo $?
     4
    
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Link: https://patch.msgid.link/20250908073238.119240-6-idosch@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b34f08d53f50e1301c7a11182e9da587b91166f7
Author: Qianfeng Rong <rongqianfeng@vivo.com>
Date:   Wed Aug 27 20:39:13 2025 +0800

    media: redrat3: use int type to store negative error codes
    
    [ Upstream commit ecba852dc9f4993f4f894ea1f352564560e19a3e ]
    
    Change "ret" from u8 to int type in redrat3_enable_detector() to store
    negative error codes or zero returned by redrat3_send_cmd() and
    usb_submit_urb() - this better aligns with the coding standards and
    maintains code consistency.
    
    No effect on runtime.
    
    Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e24def6f1064f031d07ad01a5b9ba7e0e1ab2ab
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Date:   Tue Sep 9 10:58:49 2025 +0200

    net: sh_eth: Disable WoL if system can not suspend
    
    [ Upstream commit 9c02ea544ac35a9def5827d30594406947ccd81a ]
    
    The MAC can't facilitate WoL if the system can't go to sleep. Gate the
    WoL support callbacks in ethtool at compile time using CONFIG_PM_SLEEP.
    
    Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://patch.msgid.link/20250909085849.3808169-1-niklas.soderlund+renesas@ragnatech.se
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2272d5757ce5d3fb416d9f2497b015678eb85c0d
Author: Harikrishna Shenoy <h-shenoy@ti.com>
Date:   Thu Aug 7 10:50:02 2025 +0530

    phy: cadence: cdns-dphy: Enable lower resolutions in dphy
    
    [ Upstream commit 43bd2c44515f8ee5c019ce6e6583f5640387a41b ]
    
    Enable support for data lane rates between 80-160 Mbps cdns dphy
    as mentioned in TRM [0] by setting the pll_opdiv field to 16.
    This change enables lower resolutions like 640x480 at 60Hz.
    
    [0]: https://www.ti.com/lit/zip/spruil1
    (Table 12-552. DPHY_TX_PLL_CTRL Register Field Descriptions)
    
    Reviewed-by: Udit Kumar <u-kumar1@ti.com>
    Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
    Signed-off-by: Harikrishna Shenoy <h-shenoy@ti.com>
    Link: https://lore.kernel.org/r/20250807052002.717807-1-h-shenoy@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 350483edf4782b85b02ed0e0a6d408100681fa8c
Author: Rohan G Thomas <rohan.g.thomas@altera.com>
Date:   Sat Sep 6 10:33:31 2025 +0800

    net: phy: marvell: Fix 88e1510 downshift counter errata
    
    [ Upstream commit deb105f49879dd50d595f7f55207d6e74dec34e6 ]
    
    The 88e1510 PHY has an erratum where the phy downshift counter is not
    cleared after phy being suspended(BMCR_PDOWN set) and then later
    resumed(BMCR_PDOWN cleared). This can cause the gigabit link to
    intermittently downshift to a lower speed.
    
    Disabling and re-enabling the downshift feature clears the counter,
    allowing the PHY to retry gigabit link negotiation up to the programmed
    retry count times before downshifting. This behavior has been observed
    on copper links.
    
    Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
    Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20250906-marvell_fix-v2-1-f6efb286937f@altera.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 807f13fd52f2f27aacfd16b739ced5c25072cc88
Author: William Wu <william.wu@rock-chips.com>
Date:   Tue Aug 26 18:28:07 2025 +0800

    usb: gadget: f_hid: Fix zero length packet transfer
    
    [ Upstream commit ed6f727c575b1eb8136e744acfd5e7306c9548f6 ]
    
    Set the hid req->zero flag of ep0/in_ep to true by default,
    then the UDC drivers can transfer a zero length packet at
    the end if the hid transfer with size divisible to EPs max
    packet size according to the USB 2.0 spec.
    
    Signed-off-by: William Wu <william.wu@rock-chips.com>
    Link: https://lore.kernel.org/r/1756204087-26111-1-git-send-email-william.wu@rock-chips.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30e91eeb0bc9b3daf402b26176d1d52c29ab53e4
Author: Ashish Kalra <ashish.kalra@amd.com>
Date:   Mon Aug 25 21:46:53 2025 +0000

    iommu/amd: Skip enabling command/event buffers for kdump
    
    [ Upstream commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb ]
    
    After a panic if SNP is enabled in the previous kernel then the kdump
    kernel boots with IOMMU SNP enforcement still enabled.
    
    IOMMU command buffers and event buffer registers remain locked and
    exclusive to the previous kernel. Attempts to enable command and event
    buffers in the kdump kernel will fail, as hardware ignores writes to
    the locked MMIO registers as per AMD IOMMU spec Section 2.12.2.1.
    
    Skip enabling command buffers and event buffers for kdump boot as they
    are already enabled in the previous kernel.
    
    Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
    Tested-by: Sairaj Kodilkar <sarunkod@amd.com>
    Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
    Link: https://lore.kernel.org/r/576445eb4f168b467b0fc789079b650ca7c5b037.1756157913.git.ashish.kalra@amd.com
    Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40e78a37beac76694cab4601bba15fccd68569f1
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Sep 3 17:48:10 2025 +0000

    net: call cond_resched() less often in __release_sock()
    
    [ Upstream commit 16c610162d1f1c332209de1c91ffb09b659bb65d ]
    
    While stress testing TCP I had unexpected retransmits and sack packets
    when a single cpu receives data from multiple high-throughput flows.
    
    super_netperf 4 -H srv -T,10 -l 3000 &
    
    Tcpdump extract:
    
     00:00:00.000007 IP6 clnt > srv: Flags [.], seq 26062848:26124288, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440
     00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26124288:26185728, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26185728:26243072, ack 1, win 66, options [nop,nop,TS val 651460834 ecr 3100749131], length 57344
     00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26243072:26304512, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26304512:26365952, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 61440
     00:00:00.000007 IP6 clnt > srv: Flags [P.], seq 26365952:26423296, ack 1, win 66, options [nop,nop,TS val 651460844 ecr 3100749141], length 57344
     00:00:00.000006 IP6 clnt > srv: Flags [.], seq 26423296:26484736, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [.], seq 26484736:26546176, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 61440
     00:00:00.000005 IP6 clnt > srv: Flags [P.], seq 26546176:26603520, ack 1, win 66, options [nop,nop,TS val 651460853 ecr 3100749150], length 57344
     00:00:00.003932 IP6 clnt > srv: Flags [P.], seq 26603520:26619904, ack 1, win 66, options [nop,nop,TS val 651464844 ecr 3100753141], length 16384
     00:00:00.006602 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651471419 ecr 3100759716], length 4096
     00:00:00.013000 IP6 clnt > srv: Flags [.], seq 24862720:24866816, ack 1, win 66, options [nop,nop,TS val 651484421 ecr 3100772718], length 4096
     00:00:00.000416 IP6 srv > clnt: Flags [.], ack 26619904, win 1393, options [nop,nop,TS val 3100773185 ecr 651484421,nop,nop,sack 1 {24862720:24866816}], length 0
    
    After analysis, it appears this is because of the cond_resched()
    call from  __release_sock().
    
    When current thread is yielding, while still holding the TCP socket lock,
    it might regain the cpu after a very long time.
    
    Other peer TLP/RTO is firing (multiple times) and packets are retransmit,
    while the initial copy is waiting in the socket backlog or receive queue.
    
    In this patch, I call cond_resched() only once every 16 packets.
    
    Modern TCP stack now spends less time per packet in the backlog,
    especially because ACK are no longer sent (commit 133c4c0d3717
    "tcp: defer regular ACK while processing socket backlog")
    
    Before:
    
    clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK"
    TcpOutSegs                      19046186           0.0
    TcpRetransSegs                  1471               0.0
    TcpExtTCPTimeouts               1397               0.0
    TcpExtTCPLossProbes             1356               0.0
    TcpExtTCPDSACKRecv              1352               0.0
    TcpExtTCPSpuriousRTOs           114                0.0
    TcpExtTCPDSACKRecvSegs          1352               0.0
    
    After:
    
    clnt:/# nstat -n;sleep 10;nstat|egrep "TcpOutSegs|TcpRetransSegs|TCPFastRetrans|TCPTimeouts|Probes|TCPSpuriousRTOs|DSACK"
    TcpOutSegs                      19218936           0.0
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
    Link: https://patch.msgid.link/20250903174811.1930820-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0f4bb623c0cb58e99c13d586fe971911b673239
Author: Cryolitia PukNgae <cryolitia@uniontech.com>
Date:   Wed Sep 3 13:09:48 2025 +0800

    ALSA: usb-audio: apply quirk for MOONDROP Quark2
    
    [ Upstream commit a73349c5dd27bc544b048e2e2c8ef6394f05b793 ]
    
    It reports a MIN value -15360 for volume control, but will mute when
    setting it less than -14208
    
    Tested-by: Guoli An <anguoli@uniontech.com>
    Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20250903-sound-v1-4-d4ca777b8512@uniontech.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58aa53f84f75b07ee36892184ee8540830edf436
Author: Juraj Šarinay <juraj@sarinay.com>
Date:   Tue Sep 2 13:36:28 2025 +0200

    net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms
    
    [ Upstream commit 21f82062d0f241e55dd59eb630e8710862cc90b4 ]
    
    An exchange with a NFC target must complete within NCI_DATA_TIMEOUT.
    A delay of 700 ms is not sufficient for cryptographic operations on smart
    cards. CardOS 6.0 may need up to 1.3 seconds to perform 256-bit ECDH
    or 3072-bit RSA. To prevent brute-force attacks, passports and similar
    documents introduce even longer delays into access control protocols
    (BAC/PACE).
    
    The timeout should be higher, but not too much. The expiration allows
    us to detect that a NFC target has disappeared.
    
    Signed-off-by: Juraj Šarinay <juraj@sarinay.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://patch.msgid.link/20250902113630.62393-1-juraj@sarinay.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 000087a6664f91cf70a08616a169a514178d96d9
Author: Yue Haibing <yuehaibing@huawei.com>
Date:   Mon Sep 1 20:37:26 2025 +0800

    ipv6: Add sanity checks on ipv6_devconf.rpl_seg_enabled
    
    [ Upstream commit 3d95261eeb74958cd496e1875684827dc5d028cc ]
    
    In ipv6_rpl_srh_rcv() we use min(net->ipv6.devconf_all->rpl_seg_enabled,
    idev->cnf.rpl_seg_enabled) is intended to return 0 when either value is
    zero, but if one of the values is negative it will in fact return non-zero.
    
    Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
    Link: https://patch.msgid.link/20250901123726.1972881-3-yuehaibing@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 580710dd519a27c27a5b83ce7bcc88eef8598b40
Author: Devendra K Verma <devverma@amd.com>
Date:   Thu Aug 21 17:45:05 2025 +0530

    dmaengine: dw-edma: Set status for callback_result
    
    [ Upstream commit 5e742de97c806a4048418237ef1283e7d71eaf4b ]
    
    DMA Engine has support for the callback_result which provides
    the status of the request and the residue. This helps in
    determining the correct status of the request and in
    efficient resource management of the request.
    The 'callback_result' method is preferred over the deprecated
    'callback' method.
    
    Signed-off-by: Devendra K Verma <devverma@amd.com>
    Link: https://lore.kernel.org/r/20250821121505.318179-1-devverma@amd.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb5874abca37a763447dc0d55d0a3f52ad38f33a
Author: Rosen Penev <rosenp@gmail.com>
Date:   Thu Aug 21 15:09:42 2025 -0700

    dmaengine: mv_xor: match alloc_wc and free_wc
    
    [ Upstream commit a33e3b667d2f004fdfae6b442bd4676f6c510abb ]
    
    dma_alloc_wc is used but not dma_free_wc.
    
    Signed-off-by: Rosen Penev <rosenp@gmail.com>
    Link: https://lore.kernel.org/r/20250821220942.10578-1-rosenp@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c93e9d6cdf64ba4e00e4d1d4368a921268c10d2
Author: Thomas Andreatta <thomasandreatta2000@gmail.com>
Date:   Wed Aug 27 17:24:43 2025 +0200

    dmaengine: sh: setup_xref error handling
    
    [ Upstream commit d9a3e9929452780df16f3414f0d59b5f69d058cf ]
    
    This patch modifies the type of setup_xref from void to int and handles
    errors since the function can fail.
    
    `setup_xref` now returns the (eventual) error from
    `dmae_set_dmars`|`dmae_set_chcr`, while `shdma_tx_submit` handles the
    result, removing the chunks from the queue and marking PM as idle in
    case of an error.
    
    Signed-off-by: Thomas Andreatta <thomas.andreatta2000@gmail.com>
    Link: https://lore.kernel.org/r/20250827152442.90962-1-thomas.andreatta2000@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c68af94a26c4adc15ead63fb1ead93022a031b2
Author: Qianfeng Rong <rongqianfeng@vivo.com>
Date:   Tue Aug 26 17:32:42 2025 +0800

    scsi: pm8001: Use int instead of u32 to store error codes
    
    [ Upstream commit bee3554d1a4efbce91d6eca732f41b97272213a5 ]
    
    Use int instead of u32 for 'ret' variable to store negative error codes
    returned by PM8001_CHIP_DISP->set_nvmd_req().
    
    Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
    Link: https://lore.kernel.org/r/20250826093242.230344-1-rongqianfeng@vivo.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fd1336d65d59b13356688f7d0f309439750dcb2
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Fri Aug 15 14:12:23 2025 +0200

    mips: lantiq: xway: sysctrl: rename stp clock
    
    [ Upstream commit b0d04fe6a633ada2c7bc1b5ddd011cbd85961868 ]
    
    Bindig requires a node name matching ‘^gpio@[0-9a-f]+$’. This patch
    changes the clock name from “stp” to “gpio”.
    
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 539e1815a9e92ba4ef5cd245d3c9b32cbb51dc65
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Mon Aug 11 15:34:13 2025 +0200

    mips: lantiq: danube: add missing device_type in pci node
    
    [ Upstream commit d66949a1875352d2ddd52b144333288952a9e36f ]
    
    This fixes the following warning:
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: pci@e105400 (lantiq,pci-xway): 'device_type' is a required property
            from schema $id: http://devicetree.org/schemas/pci/pci-bus-common.yaml#
    
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7bc7086b25776aa67d03bd798cf5b237b08b1a1
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Mon Aug 11 13:58:15 2025 +0200

    mips: lantiq: danube: add missing properties to cpu node
    
    [ Upstream commit e8dee66c37085dc9858eb8608bc783c2900e50e7 ]
    
    This fixes the following warnings:
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#address-cells' is a required property
            from schema $id: http://devicetree.org/schemas/cpus.yaml#
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpus: '#size-cells' is a required property
            from schema $id: http://devicetree.org/schemas/cpus.yaml#
    arch/mips/boot/dts/lantiq/danube_easy50712.dtb: cpu@0 (mips,mips24Kc): 'reg' is a required property
            from schema $id: http://devicetree.org/schemas/mips/cpus.yaml#
    
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58f438a99551205df432e829bfce6ced5f604341
Author: Chelsy Ratnawat <chelsyratnawat2001@gmail.com>
Date:   Wed Aug 6 23:09:36 2025 -0700

    media: fix uninitialized symbol warnings
    
    [ Upstream commit b4c441310c3baaa7c39a5457e305ca93c7a0400d ]
    
    Initialize variables to fix these smatch warnings
    drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized
    symbol 'protocol'.
    drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized
    symbol 'scancode'.
    drivers/media/i2c/ir-kbd-i2c.c:339 ir_key_poll() error: uninitialized
    symbol 'toggle'.
    drivers/media/tuners/xc4000.c:1102 xc_debug_dump() error: uninitialized
    symbol 'adc_envelope'.
    drivers/media/tuners/xc4000.c:1108 xc_debug_dump() error: uninitialized
    symbol 'lock_status'.
    drivers/media/tuners/xc4000.c:1123 xc_debug_dump() error: uninitialized
    symbol 'frame_lines'.
    drivers/media/tuners/xc4000.c:1127 xc_debug_dump() error: uninitialized
    symbol 'quality'.
    drivers/media/tuners/xc5000.c:645 xc_debug_dump() error: uninitialized
    symbol 'adc_envelope'.
    drivers/media/tuners/xc5000.c:651 xc_debug_dump() error: uninitialized
    symbol 'lock_status'.
    drivers/media/tuners/xc5000.c:665 xc_debug_dump() error: uninitialized
    symbol 'frame_lines'.
    drivers/media/tuners/xc5000.c:668 xc_debug_dump() error: uninitialized
    symbol 'quality'.
    drivers/media/tuners/xc5000.c:671 xc_debug_dump() error: uninitialized
    symbol 'snr'.
    drivers/media/tuners/xc5000.c:674 xc_debug_dump() error: uninitialized
    symbol 'totalgain'.
    
    Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    [hverkuil: dropped ' = 0' from rc in ir-kbd-i2c.c, not needed]
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00541c4742e307c80eb40aac313a4aa6cac3207a
Author: Amber Lin <Amber.Lin@amd.com>
Date:   Fri Aug 15 14:04:15 2025 -0400

    drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption
    
    [ Upstream commit f3820e9d356132e18405cd7606e22dc87ccfa6d1 ]
    
    When KFD asks CP to preempt queues, other than preempt CP queues, CP
    also requests SDMA to preempt SDMA queues with UNMAP_LATENCY timeout.
    Currently queue_preemption_timeout_ms is 9000 ms by default but can be
    configured via module parameter. KFD_UNMAP_LATENCY_MS is hard coded as
    4000 ms though. This patch ties KFD_UNMAP_LATENCY_MS to
    queue_preemption_timeout_ms so in a slow system such as emulator, both
    CP and SDMA slowness are taken into account.
    
    Signed-off-by: Amber Lin <Amber.Lin@amd.com>
    Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78f2011a7f2fe5986ff188a4baf982b7a2d067d1
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu May 1 16:33:21 2025 +0200

    extcon: adc-jack: Fix wakeup source leaks on device unbind
    
    [ Upstream commit 78b6a991eb6c6f19ed7d0ac91cda3b3b117fda8f ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.  Do not use devm interface, because it would change the order of
    cleanup.
    
    Link: https://lore.kernel.org/lkml/20250501-device-wakeup-leak-extcon-v2-1-7af77802cbea@linaro.org/
    Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 583cfe2940eb0dd4d0df0f419a4ac4cc5e62a499
Author: Francisco Gutierrez <frankramirez@google.com>
Date:   Wed Jul 23 18:35:43 2025 +0000

    scsi: pm80xx: Fix race condition caused by static variables
    
    [ Upstream commit d6477ee38ccfbeaed885733c13f41d9076e2f94a ]
    
    Eliminate the use of static variables within the log pull implementation
    to resolve a race condition and prevent data gaps when pulling logs from
    multiple controllers in parallel, ensuring each operation is properly
    isolated.
    
    Signed-off-by: Francisco Gutierrez <frankramirez@google.com>
    Link: https://lore.kernel.org/r/20250723183543.1443301-1-frankramirez@google.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f16464c7efce3c5937c3700a9d30dc506fd27dc
Author: Ujwal Kundur <ujwal.kundur@gmail.com>
Date:   Wed Aug 20 23:25:49 2025 +0530

    rds: Fix endianness annotation for RDS_MPATH_HASH
    
    [ Upstream commit 77907a068717fbefb25faf01fecca553aca6ccaa ]
    
    jhash_1word accepts host endian inputs while rs_bound_port is a be16
    value (sockaddr_in6.sin6_port). Use ntohs() for consistency.
    
    Flagged by Sparse.
    
    Signed-off-by: Ujwal Kundur <ujwal.kundur@gmail.com>
    Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
    Link: https://patch.msgid.link/20250820175550.498-4-ujwal.kundur@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16ad41a1ef9ba418bd5fba403d845285bfb72733
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 21 17:17:50 2025 +0200

    ALSA: usb-audio: Add validation of UAC2/UAC3 effect units
    
    [ Upstream commit 2aec0b6a6b5395bca7d6fde9c7e9dc391d329698 ]
    
    Just add fixed struct size validations for UAC2 and UAC3 effect
    units.  The descriptor has a variable-length array, so it should be
    validated with a proper function later once when the unit is really
    parsed and used by the driver (currently only referred partially for
    the input terminal parsing).
    
    Link: https://patch.msgid.link/20250821151751.12100-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c4bf5c9adfa7079a6b099a788c04cef5bd1028b
Author: Sungho Kim <sungho.kim@furiosa.ai>
Date:   Wed Aug 20 19:57:14 2025 +0900

    PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call
    
    [ Upstream commit 6238784e502b6a9fbeb3a6b77284b29baa4135cc ]
    
    The error handling path in pci_p2pdma_add_resource() contains a bug in its
    `pgmap_free` label.
    
    Memory is allocated for the `p2p_pgmap` struct, and the pointer is stored
    in `p2p_pgmap`. However, the error path calls devm_kfree() with `pgmap`,
    which is a pointer to a member field within the `p2p_pgmap` struct, not the
    base pointer of the allocation.
    
    Correct the bug by passing the correct base pointer, `p2p_pgmap`, to
    devm_kfree().
    
    Signed-off-by: Sungho Kim <sungho.kim@furiosa.ai>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Link: https://patch.msgid.link/20250820105714.2939896-1-sungho.kim@furiosa.ai
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01a1d4e492f899acd928f03a90314a50e2ca4e28
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Fri Aug 15 20:16:12 2025 +0000

    net: Call trace_sock_exceed_buf_limit() for memcg failure with SK_MEM_RECV.
    
    [ Upstream commit 9d85c565a7b7c78b732393c02bcaa4d5c275fe58 ]
    
    Initially, trace_sock_exceed_buf_limit() was invoked when
    __sk_mem_raise_allocated() failed due to the memcg limit or the
    global limit.
    
    However, commit d6f19938eb031 ("net: expose sk wmem in
    sock_exceed_buf_limit tracepoint") somehow suppressed the event
    only when memcg failed to charge for SK_MEM_RECV, although the
    memcg failure for SK_MEM_SEND still triggers the event.
    
    Let's restore the event for SK_MEM_RECV.
    
    Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
    Link: https://patch.msgid.link/20250815201712.1745332-5-kuniyu@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b7aec038a30eade10e19a3d274223d4d6cdef58
Author: Christoph Paasch <cpaasch@openai.com>
Date:   Sat Aug 16 16:12:49 2025 -0700

    net: When removing nexthops, don't call synchronize_net if it is not necessary
    
    [ Upstream commit b0ac6d3b56a2384db151696cfda2836a8a961b6d ]
    
    When removing a nexthop, commit
    90f33bffa382 ("nexthops: don't modify published nexthop groups") added a
    call to synchronize_rcu() (later changed to _net()) to make sure
    everyone sees the new nexthop-group before the rtnl-lock is released.
    
    When one wants to delete a large number of groups and nexthops, it is
    fastest to first flush the groups (ip nexthop flush groups) and then
    flush the nexthops themselves (ip -6 nexthop flush). As that way the
    groups don't need to be rebalanced.
    
    However, `ip -6 nexthop flush` will still take a long time if there is
    a very large number of nexthops because of the call to
    synchronize_net(). Now, if there are no more groups, there is no point
    in calling synchronize_net(). So, let's skip that entirely by checking
    if nh->grp_list is empty.
    
    This gives us a nice speedup:
    
    BEFORE:
    =======
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 2097152 nexthops
    
    real    1m45.345s
    user    0m0.001s
    sys     0m0.005s
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 4194304 nexthops
    
    real    3m10.430s
    user    0m0.002s
    sys     0m0.004s
    
    AFTER:
    ======
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 2097152 nexthops
    
    real    0m17.545s
    user    0m0.003s
    sys     0m0.003s
    
    $ time sudo ip -6 nexthop flush
    Dump was interrupted and may be inconsistent.
    Flushed 4194304 nexthops
    
    real    0m35.823s
    user    0m0.002s
    sys     0m0.004s
    
    Signed-off-by: Christoph Paasch <cpaasch@openai.com>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/20250816-nexthop_dump-v2-2-491da3462118@openai.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bab531efaa9f3740000d167e5d1c8a78113ab8eb
Author: Zijun Hu <zijun.hu@oss.qualcomm.com>
Date:   Mon Jul 14 23:34:17 2025 +0800

    char: misc: Does not request module for miscdevice with dynamic minor
    
    [ Upstream commit 1ba0fb42aa6a5f072b1b8c0b0520b32ad4ef4b45 ]
    
    misc_open() may request module for miscdevice with dynamic minor, which
    is meaningless since:
    
    - The dynamic minor allocated is unknown in advance without registering
      miscdevice firstly.
    - Macro MODULE_ALIAS_MISCDEV() is not applicable for dynamic minor.
    
    Fix by only requesting module for miscdevice with fixed minor.
    
    Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250714-rfc_miscdev-v6-6-2ed949665bde@oss.qualcomm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa24a2584eb8f09d32ea5451ecebc0a7b0e3bb8e
Author: raub camaioni <raubcameo@gmail.com>
Date:   Fri Aug 15 09:07:21 2025 -0400

    usb: gadget: f_ncm: Fix MAC assignment NCM ethernet
    
    [ Upstream commit 956606bafb5fc6e5968aadcda86fc0037e1d7548 ]
    
    This fix is already present in f_ecm.c and was never
    propagated to f_ncm.c
    
    When creating multiple NCM ethernet devices
    on a composite usb gadget device
    each MAC address on the HOST side will be identical.
    Having the same MAC on different network interfaces is bad.
    
    This fix updates the MAC address inside the
    ncm_strings_defs global during the ncm_bind call.
    This ensures each device has a unique MAC.
    In f_ecm.c ecm_string_defs is updated in the same way.
    
    The defunct MAC assignment in ncm_alloc has been removed.
    
    Signed-off-by: raub camaioni <raubcameo@gmail.com>
    Link: https://lore.kernel.org/r/20250815131358.1047525-1-raubcameo@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 459b43be89622fc64c37a99652095b5c288a02fb
Author: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
Date:   Thu Jul 17 19:13:49 2025 -0300

    iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg sample before setting register
    
    [ Upstream commit d75c7021c08e8ae3f311ef2464dca0eaf75fab9f ]
    
    avg sample info is a bit field coded inside the following
    bits: 5,6,7 and 8 of a device status register.
    
    Channel num info the same, but over bits: 1, 2 and 3.
    
    Mask both values in order to avoid touching other register bits,
    since the first info (avg sample), came from DT.
    
    Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Link: https://patch.msgid.link/20250717221559.158872-1-rodrigo.gobbi.7@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8aa0edef2490cf533d95ec3031558fd1ac8d7aeb
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Date:   Sat Aug 2 13:40:35 2025 +0300

    drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts
    
    [ Upstream commit cb640b2ca54617f4a9d4d6efd5ff2afd6be11f19 ]
    
    Detecting the monitor for DisplayPort targets is more complicated than
    just reading the HPD pin level: it requires reading the DPCD in order to
    check what kind of device is attached to the port and whether there is
    an actual display attached.
    
    In order to let DRM framework handle such configurations, disable
    DRM_BRIDGE_OP_DETECT for dp-connector devices, letting the actual DP
    driver perform detection. This still keeps DRM_BRIDGE_OP_HPD enabled, so
    it is valid for the bridge to report HPD events.
    
    Currently inside the kernel there are only two targets which list
    hpd-gpios for dp-connector devices: arm64/qcom/qcs6490-rb3gen2 and
    arm64/qcom/sa8295p-adp. Both should be fine with this change.
    
    Cc: Bjorn Andersson <andersson@kernel.org>
    Cc: Konrad Dybcio <konradybcio@kernel.org>
    Cc: linux-arm-msm@vger.kernel.org
    Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Link: https://lore.kernel.org/r/20250802-dp-conn-no-detect-v1-1-2748c2b946da@oss.qualcomm.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f58ab83b7b7133e6baefe03a46846c4f6ce45e2f
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Thu Jul 17 23:21:55 2025 +0900

    media: imon: make send_packet() more robust
    
    [ Upstream commit eecd203ada43a4693ce6fdd3a58ae10c7819252c ]
    
    syzbot is reporting that imon has three problems which result in
    hung tasks due to forever holding device lock [1].
    
    First problem is that when usb_rx_callback_intf0() once got -EPROTO error
    after ictx->dev_present_intf0 became true, usb_rx_callback_intf0()
    resubmits urb after printk(), and resubmitted urb causes
    usb_rx_callback_intf0() to again get -EPROTO error. This results in
    printk() flooding (RCU stalls).
    
    Alan Stern commented [2] that
    
      In theory it's okay to resubmit _if_ the driver has a robust
      error-recovery scheme (such as giving up after some fixed limit on the
      number of errors or after some fixed time has elapsed, perhaps with a
      time delay to prevent a flood of errors).  Most drivers don't bother to
      do this; they simply give up right away.  This makes them more
      vulnerable to short-term noise interference during USB transfers, but in
      reality such interference is quite rare.  There's nothing really wrong
      with giving up right away.
    
    but imon has a poor error-recovery scheme which just retries forever;
    this behavior should be fixed.
    
    Since I'm not sure whether it is safe for imon users to give up upon any
    error code, this patch takes care of only union of error codes chosen from
    modules in drivers/media/rc/ directory which handle -EPROTO error (i.e.
    ir_toy, mceusb and igorplugusb).
    
    Second problem is that when usb_rx_callback_intf0() once got -EPROTO error
    before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always
    resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge
    hardware after early callbacks"). Move the ictx->dev_present_intf0 test
    introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes
    until intf configured") to immediately before imon_incoming_packet(), or
    the first problem explained above happens without printk() flooding (i.e.
    hung task).
    
    Third problem is that when usb_rx_callback_intf0() is not called for some
    reason (e.g. flaky hardware; the reproducer for this problem sometimes
    prevents usb_rx_callback_intf0() from being called),
    wait_for_completion_interruptible() in send_packet() never returns (i.e.
    hung task). As a workaround for such situation, change send_packet() to
    wait for completion with timeout of 10 seconds.
    
    Link: https://syzkaller.appspot.com/bug?extid=592e2ab8775dbe0bf09a [1]
    Link: https://lkml.kernel.org/r/d6da6709-d799-4be3-a695-850bddd6eb24@rowland.harvard.edu [2]
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9bf27de51bd6db5ff827780ec0eba55de230ba45
Author: Charalampos Mitrodimas <charmitro@posteo.net>
Date:   Tue Aug 12 15:51:25 2025 +0000

    net: ipv6: fix field-spanning memcpy warning in AH output
    
    [ Upstream commit 2327a3d6f65ce2fe2634546dde4a25ef52296fec ]
    
    Fix field-spanning memcpy warnings in ah6_output() and
    ah6_output_done() where extension headers are copied to/from IPv6
    address fields, triggering fortify-string warnings about writes beyond
    the 16-byte address fields.
    
      memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16)
      WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439
    
    The warnings are false positives as the extension headers are
    intentionally placed after the IPv6 header in memory. Fix by properly
    copying addresses and extension headers separately, and introduce
    helper functions to avoid code duplication.
    
    Reported-by: syzbot+01b0667934cdceb4451c@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=01b0667934cdceb4451c
    Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b23d8085816a6cc29639a3fe8d727e121cf40c4
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Tue Aug 12 11:02:12 2025 +0300

    bridge: Redirect to backup port when port is administratively down
    
    [ Upstream commit 3d05b24429e1de7a17c8fdccb04a04dbc8ad297b ]
    
    If a backup port is configured for a bridge port, the bridge will
    redirect known unicast traffic towards the backup port when the primary
    port is administratively up but without a carrier. This is useful, for
    example, in MLAG configurations where a system is connected to two
    switches and there is a peer link between both switches. The peer link
    serves as the backup port in case one of the switches loses its
    connection to the multi-homed system.
    
    In order to avoid flooding when the primary port loses its carrier, the
    bridge does not flush dynamic FDB entries pointing to the port upon STP
    disablement, if the port has a backup port.
    
    The above means that known unicast traffic destined to the primary port
    will be blackholed when the port is put administratively down, until the
    FDB entries pointing to it are aged-out.
    
    Given that the current behavior is quite weird and unlikely to be
    depended on by anyone, amend the bridge to redirect to the backup port
    also when the primary port is administratively down and not only when it
    does not have a carrier.
    
    The change is motivated by a report from a user who expected traffic to
    be redirected to the backup port when the primary port was put
    administratively down while debugging a network issue.
    
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://patch.msgid.link/20250812080213.325298-2-idosch@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a332080042d6027c9f17513297cbf7a529746d2
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Thu Aug 7 15:55:40 2025 +0200

    powerpc/eeh: Use result of error_detected() in uevent
    
    [ Upstream commit 704e5dd1c02371dfc7d22e1520102b197a3b628b ]
    
    Ever since uevent support was added for AER and EEH with commit
    856e1eb9bdd4 ("PCI/AER: Add uevents in AER and EEH error/resume"), it
    reported PCI_ERS_RESULT_NONE as uevent when recovery begins.
    
    Commit 7b42d97e99d3 ("PCI/ERR: Always report current recovery status for
    udev") subsequently amended AER to report the actual return value of
    error_detected().
    
    Make the same change to EEH to align it with AER and s390.
    
    Suggested-by: Lukas Wunner <lukas@wunner.de>
    Link: https://lore.kernel.org/linux-pci/aIp6LiKJor9KLVpv@wunner.de/
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Lukas Wunner <lukas@wunner.de>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Acked-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Link: https://patch.msgid.link/20250807-add_err_uevents-v5-3-adf85b0620b0@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f1ba6ecb23f711ba2e88afdfe15c6e29d08eaaf
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Mon Aug 11 15:35:04 2025 +0800

    net: stmmac: Check stmmac_hw_setup() in stmmac_resume()
    
    [ Upstream commit 6896c2449a1858acb643014894d01b3a1223d4e5 ]
    
    stmmac_hw_setup() may return 0 on success and an appropriate negative
    integer as defined in errno.h file on failure, just check it and then
    return early if failed in stmmac_resume().
    
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
    Link: https://patch.msgid.link/20250811073506.27513-2-yangtiezhu@loongson.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit adaf98cf46d9dc832e59df0a5dc8f71b262c69f4
Author: Kiryl Shutsemau <kas@kernel.org>
Date:   Tue Jun 24 17:59:18 2025 +0300

    x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall
    
    [ Upstream commit 8ba38a7a9a699905b84fa97578a8291010dec273 ]
    
    emulate_vsyscall() expects to see X86_PF_INSTR in PFEC on a vsyscall
    page fault, but the CPU does not report X86_PF_INSTR if neither
    X86_FEATURE_NX nor X86_FEATURE_SMEP are enabled.
    
    X86_FEATURE_NX should be enabled on nearly all 64-bit CPUs, except for
    early P4 processors that did not support this feature.
    
    Instead of explicitly checking for X86_PF_INSTR, compare the fault
    address to RIP.
    
    On machines with X86_FEATURE_NX enabled, issue a warning if RIP is equal
    to fault address but X86_PF_INSTR is absent.
    
    [ dhansen: flesh out code comments ]
    
    Originally-by: Dave Hansen <dave.hansen@intel.com>
    Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Link: https://lore.kernel.org/all/bd81a98b-f8d4-4304-ac55-d4151a1a77ab@intel.com
    Link: https://lore.kernel.org/all/20250624145918.2720487-1-kirill.shutemov%40linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fa279ed874ab72503e2f8ccd9841bd412f028ea
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Wed Jul 23 13:05:09 2025 +0300

    drm/tidss: Use the crtc_* timings when programming the HW
    
    [ Upstream commit 478306edc23eec4f0ec24a46222485910c66212d ]
    
    Use the crtc_* fields from drm_display_mode, instead of the "logical"
    fields. This shouldn't change anything in practice, but afaiu the crtc_*
    fields are the correct ones to use here.
    
    Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev>
    Tested-by: Parth Pancholi <parth.pancholi@toradex.com>
    Tested-by: Jayesh Choudhary <j-choudhary@ti.com>
    Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
    Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-3-e61cc06074c2@ideasonboard.com
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8df5aec0298b1c6b96d198b85c78c022a422b533
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Sun Aug 10 04:29:54 2025 +0300

    media: pci: ivtv: Don't create fake v4l2_fh
    
    [ Upstream commit cc6e8d1ccea792d8550428e0831e3a35b0ccfddc ]
    
    The ivtv driver has a structure named ivtv_open_id that models an open
    file handle for the device. It embeds a v4l2_fh instance for file
    handles that correspond to a V4L2 video device, and stores a pointer to
    that v4l2_fh in struct ivtv_stream to identify which open file handle
    owns a particular stream.
    
    In addition to video devices, streams can be owned by ALSA PCM devices.
    Those devices do not make use of the v4l2_fh instance for obvious
    reasons, but the snd_ivtv_pcm_capture_open() function still initializes
    a "fake" v4l2_fh for the sole purpose of using it as an open file handle
    identifier. The v4l2_fh is not properly destroyed when the ALSA PCM
    device is closed, leading to possible resource leaks.
    
    Fortunately, the v4l2_fh instance pointed to by ivtv_stream is not
    accessed, only the pointer value is used for comparison. Replace it with
    a pointer to the ivtv_open_id structure that embeds the v4l2_fh, and
    don't initialize the v4l2_fh for ALSA PCM devices.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d906671e0136bf0081a49913d71054b11b43798f
Author: Geoffrey McRae <geoffrey.mcrae@amd.com>
Date:   Tue Jul 8 13:53:40 2025 +1000

    drm/amdkfd: return -ENOTTY for unsupported IOCTLs
    
    [ Upstream commit 57af162bfc8c05332a28c4d458d246cc46d2746d ]
    
    Some kfd ioctls may not be available depending on the kernel version the
    user is running, as such we need to report -ENOTTY so userland can
    determine the cause of the ioctl failure.
    
    Signed-off-by: Geoffrey McRae <geoffrey.mcrae@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e932554c7653280a3243defabb7db148ce818f95
Author: Wake Liu <wakel@google.com>
Date:   Sat Aug 9 14:20:13 2025 +0800

    selftests/net: Ensure assert() triggers in psock_tpacket.c
    
    [ Upstream commit bc4c0a48bdad7f225740b8e750fdc1da6d85e1eb ]
    
    The get_next_frame() function in psock_tpacket.c was missing a return
    statement in its default switch case, leading to a compiler warning.
    
    This was caused by a `bug_on(1)` call, which is defined as an
    `assert()`, being compiled out because NDEBUG is defined during the
    build.
    
    Instead of adding a `return NULL;` which would silently hide the error
    and could lead to crashes later, this change restores the original
    author's intent. By adding `#undef NDEBUG` before including <assert.h>,
    we ensure the assertion is active and will cause the test to abort if
    this unreachable code is ever executed.
    
    Signed-off-by: Wake Liu <wakel@google.com>
    Link: https://patch.msgid.link/20250809062013.2407822-1-wakel@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c465773d17cea2083bb6e471629b7115442f4399
Author: Wake Liu <wakel@google.com>
Date:   Thu Aug 7 16:09:32 2025 +0800

    selftests/net: Replace non-standard __WORDSIZE with sizeof(long) * 8
    
    [ Upstream commit c36748e8733ef9c5f4cd1d7c4327994e5b88b8df ]
    
    The `__WORDSIZE` macro, defined in the non-standard `<bits/wordsize.h>`
    header, is a GNU extension and not universally available with all
    toolchains, such as Clang when used with musl libc.
    
    This can lead to build failures in environments where this header is
    missing.
    
    The intention of the code is to determine the bit width of a C `long`.
    Replace the non-portable `__WORDSIZE` with the standard and portable
    `sizeof(long) * 8` expression to achieve the same result.
    
    This change also removes the inclusion of the now-unused
    `<bits/wordsize.h>` header.
    
    Signed-off-by: Wake Liu <wakel@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 04af23c99354bd96dd2f67283fa64e795b8c0d04
Author: Marcos Del Sol Vives <marcos@orca.pet>
Date:   Sun Jul 6 01:32:08 2025 +0200

    PCI: Disable MSI on RDC PCI to PCIe bridges
    
    [ Upstream commit ebc7086b39e5e4f3d3ca82caaea20538c9b62d42 ]
    
    RDC PCI to PCIe bridges, present on Vortex86DX3 and Vortex86EX2 SoCs, do
    not support MSIs. If enabled, interrupts generated by PCIe devices never
    reach the processor.
    
    I have contacted the manufacturer (DM&P) and they confirmed that PCI MSIs
    need to be disabled for them.
    
    Signed-off-by: Marcos Del Sol Vives <marcos@orca.pet>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Link: https://patch.msgid.link/20250705233209.721507-1-marcos@orca.pet
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e12a11f2e8d6e283c984c4882dffd3ae1feebb48
Author: Seyediman Seyedarab <imandevel@gmail.com>
Date:   Thu Jul 24 15:59:13 2025 -0400

    drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf()
    
    [ Upstream commit 6510b62fe9303aaf48ff136ff69186bcfc32172d ]
    
    snprintf() returns the number of characters that *would* have been
    written, which can overestimate how much you actually wrote to the
    buffer in case of truncation. That leads to 'data += this' advancing
    the pointer past the end of the buffer and size going negative.
    
    Switching to scnprintf() prevents potential buffer overflows and ensures
    consistent behavior when building the output string.
    
    Signed-off-by: Seyediman Seyedarab <ImanDevel@gmail.com>
    Link: https://lore.kernel.org/r/20250724195913.60742-1-ImanDevel@gmail.com
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ee066bb433edcba4db510299463752825906090
Author: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Date:   Tue Aug 5 21:28:25 2025 +0530

    drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff
    
    [ Upstream commit 0e7581eda8c76d1ca4cf519631a4d4eb9f82b94c ]
    
    Acquire jpeg_pg_lock before changes to jpeg power state
    and release it after power off from idle work handler.
    
    Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 620787119217b5abaa9504c1276936de26f410d8
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Fri Jul 11 12:18:04 2025 +0530

    drm/amd/pm: Use cached metrics data on arcturus
    
    [ Upstream commit 2f3b1ccf83be83a3330e38194ddfd1a91fec69be ]
    
    Cached metrics data validity is 1ms on arcturus. It's not reasonable for
    any client to query gpu_metrics at a faster rate and constantly
    interrupt PMFW.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Asad Kamal <asad.kamal@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 734175f5926aacee37517f4d92d664d6aeb5a1be
Author: Jens Kehne <jens.kehne@agilent.com>
Date:   Mon Aug 4 15:37:54 2025 +0200

    mfd: da9063: Split chip variant reading in two bus transactions
    
    [ Upstream commit 9ac4890ac39352ccea132109e32911495574c3ec ]
    
    We observed the initial probe of the da9063 failing in
    da9063_get_device_type in about 30% of boots on a Xilinx ZynqMP based
    board. The problem originates in da9063_i2c_blockreg_read, which uses
    a single bus transaction to turn the register page and then read a
    register. On the bus, this should translate to a write to register 0,
    followed by a read to the target register, separated by a repeated
    start. However, we found that after the write to register 0, the
    controller sometimes continues directly with the register address of
    the read request, without sending the chip address or a repeated start
    in between, which makes the read request invalid.
    
    To fix this, separate turning the page and reading the register into
    two separate transactions. This brings the initialization code in line
    with the rest of the driver, which uses register maps (which to my
    knowledge do not use repeated starts after turning the page). This has
    been included in our kernel for several months and was recently
    included in a shipped product. For us, it reliably fixes the issue,
    and we have not observed any new issues.
    
    While the underlying problem is probably with the i2c controller or
    its driver, I still propose a change here in the interest of
    robustness: First, I'm not sure this issue can be fixed on the
    controller side, since there are other issues related to repeated
    start which can't (AR# 60695, AR# 61664). Second, similar problems
    might exist with other controllers.
    
    Signed-off-by: Jens Kehne <jens.kehne@agilent.com>
    Link: https://lore.kernel.org/r/20250804133754.3496718-1-jens.kehne@agilent.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d33e5be1aee6f5b99e74a6536d7a7e1436c136b0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Aug 7 09:19:28 2025 +0200

    mfd: madera: Work around false-positive -Wininitialized warning
    
    [ Upstream commit 364752aa0c6ab0a06a2d5bfdb362c1ca407f1a30 ]
    
    clang-21 warns about one uninitialized variable getting dereferenced
    in madera_dev_init:
    
    drivers/mfd/madera-core.c:739:10: error: variable 'mfd_devs' is uninitialized when used here [-Werror,-Wuninitialized]
      739 |                               mfd_devs, n_devs,
          |                               ^~~~~~~~
    drivers/mfd/madera-core.c:459:33: note: initialize the variable 'mfd_devs' to silence this warning
      459 |         const struct mfd_cell *mfd_devs;
          |                                        ^
          |                                         = NULL
    
    The code is actually correct here because n_devs is only nonzero
    when mfd_devs is a valid pointer, but this is impossible for the
    compiler to see reliably.
    
    Change the logic to check for the pointer as well, to make this easier
    for the compiler to follow.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20250807071932.4085458-1-arnd@kernel.org
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bf1f295c54efa570385eb2a37a033bb356871f8
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Jul 25 09:11:50 2025 +0200

    mfd: stmpe-i2c: Add missing MODULE_LICENSE
    
    [ Upstream commit 00ea54f058cd4cb082302fe598cfe148e0aadf94 ]
    
    This driver is licensed GPL-2.0-only, so add the corresponding module flag.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20250725071153.338912-3-alexander.stein@ew.tq-group.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b834fc63a0df785e6a43bf5f5d526f029d814662
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Jul 25 09:07:48 2025 +0200

    mfd: stmpe: Remove IRQ domain upon removal
    
    [ Upstream commit 57bf2a312ab2d0bc8ee0f4e8a447fa94a2fc877d ]
    
    The IRQ domain is (optionally) added during stmpe_probe, but never removed.
    Add the call to stmpe_remove.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20250725070752.338376-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c6fbed407756b637452b2c16842346caa7cc5c58
Author: Len Brown <len.brown@intel.com>
Date:   Fri Sep 19 15:56:46 2025 -0400

    tools/power x86_energy_perf_policy: Prefer driver HWP limits
    
    [ Upstream commit 2734fdbc9bb8a3aeb309ba0d62212d7f53f30bc7 ]
    
    When we are successful in using cpufreq min/max limits,
    skip setting the raw MSR limits entirely.
    
    This is necessary to avoid undoing any modification that
    the cpufreq driver makes to our sysfs request.
    
    eg. intel_pstate may take our request for a limit
    that is valid according to HWP.CAP.MIN/MAX and clip
    it to be within the range available in PLATFORM_INFO.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e90c163ab51d5c294ae1f14a2ce27c5241cb86f3
Author: Len Brown <len.brown@intel.com>
Date:   Fri Sep 19 14:07:02 2025 -0400

    tools/power x86_energy_perf_policy: Enhance HWP enable
    
    [ Upstream commit c97c057d357c4b39b153e9e430bbf8976e05bd4e ]
    
    On enabling HWP, preserve the reserved bits in MSR_PM_ENABLE.
    
    Also, skip writing the MSR_PM_ENABLE if HWP is already enabled.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b94a7f38747212abdd825ce128bffe57cc39b96e
Author: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Date:   Wed Aug 13 12:32:08 2025 +0530

    tools/power x86_energy_perf_policy: Fix incorrect fopen mode usage
    
    [ Upstream commit 62127655b7ab7b8c2997041aca48a81bf5c6da0c ]
    
    The fopen_or_die() function was previously hardcoded
    to open files in read-only mode ("r"), ignoring the
    mode parameter passed to it. This patch corrects
    fopen_or_die() to use the provided mode argument,
    allowing for flexible file access as intended.
    
    Additionally, the call to fopen_or_die() in
    err_on_hypervisor() incorrectly used the mode
    "ro", which is not a valid fopen mode. This is
    fixed to use the correct "r" mode.
    
    Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45fa343129748c7a6802c058c9e4a3841f9c2392
Author: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Date:   Wed Sep 17 10:38:20 2025 +0530

    tools/cpupower: Fix incorrect size in cpuidle_state_disable()
    
    [ Upstream commit 23199d2aa6dcaf6dd2da772f93d2c94317d71459 ]
    
    Fix incorrect size parameter passed to cpuidle_state_write_file() in
    cpuidle_state_disable().
    
    The function was incorrectly using sizeof(disable) which returns the
    size of the unsigned int variable (4 bytes) instead of the actual
    length of the string stored in the 'value' buffer.
    
    Since 'value' is populated with snprintf() to contain the string
    representation of the disable value, we should use the length
    returned by snprintf() to get the correct string length for
    writing to the sysfs file.
    
    This ensures the correct number of bytes is written to the cpuidle
    state disable file in sysfs.
    
    Link: https://lore.kernel.org/r/20250917050820.1785377-1-kaushlendra.kumar@intel.com
    Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76b009addb0c6b27a72862dba888677107098737
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Wed Sep 17 20:10:36 2025 +0200

    hwmon: (dell-smm) Add support for Dell OptiPlex 7040
    
    [ Upstream commit 53d3bd48ef6ff1567a75ca77728968f5ab493cb4 ]
    
    The Dell OptiPlex 7040 supports the legacy SMM interface for reading
    sensors and performing fan control. Whitelist this machine so that
    this driver loads automatically.
    
    Closes: https://github.com/Wer-Wolf/i8kutils/issues/15
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20250917181036.10972-5-W_Armin@gmx.de
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c034463379bfaa6b76bd5b441471420c5e796175
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Tue Sep 16 23:52:57 2025 +0200

    uprobe: Do not emulate/sstep original instruction when ip is changed
    
    [ Upstream commit 4363264111e1297fa37aa39b0598faa19298ecca ]
    
    If uprobe handler changes instruction pointer we still execute single
    step) or emulate the original instruction and increment the (new) ip
    with its length.
    
    This makes the new instruction pointer bogus and application will
    likely crash on illegal instruction execution.
    
    If user decided to take execution elsewhere, it makes little sense
    to execute the original instruction, so let's skip it.
    
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20250916215301.664963-3-jolsa@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e8c3173a79c44cbd74be59410fcfa10da556ea4
Author: Daniel Lezcano <daniel.lezcano@linaro.org>
Date:   Mon Aug 4 17:23:19 2025 +0200

    clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel
    
    [ Upstream commit 0b781f527d6f99e68e5b3780ae03cd69a7cb5c0c ]
    
    The driver uses the raw_readl() and raw_writel() functions. Those are
    not for MMIO devices. Replace them with readl() and writel()
    
    [ dlezcano: Fixed typo in the subject s/reald/readl/ ]
    
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20250804152344.1109310-2-daniel.lezcano@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 574112e94a37d310be3949fcfd114c54dff9f990
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Sep 19 13:22:20 2025 +0200

    cpuidle: Fail cpuidle device registration if there is one already
    
    [ Upstream commit 7b1b7961170e4fcad488755e5ffaaaf9bd527e8f ]
    
    Refuse to register a cpuidle device if the given CPU has a cpuidle
    device already and print a message regarding it.
    
    Without this, an attempt to register a new cpuidle device without
    unregistering the existing one leads to the removal of the existing
    cpuidle device without removing its sysfs interface.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00707ed55951a5c5f4630d437d90df228ae402bb
Author: Svyatoslav Ryhel <clamor95@gmail.com>
Date:   Tue Sep 9 10:43:04 2025 +0300

    video: backlight: lp855x_bl: Set correct EPROM start for LP8556
    
    [ Upstream commit 07c7efda24453e05951fb2879f5452b720b91169 ]
    
    According to LP8556 datasheet EPROM region starts at 0x98 so adjust value
    in the driver accordingly.
    
    Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
    Reviewed-by: "Daniel Thompson (RISCstar)" <danielt@kernel.org>
    Link: https://lore.kernel.org/r/20250909074304.92135-2-clamor95@gmail.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de3d91af47bc015031e7721b100a29989f6498a5
Author: Daniel Wagner <wagi@kernel.org>
Date:   Tue Sep 2 12:22:03 2025 +0200

    nvme-fc: use lock accessing port_state and rport state
    
    [ Upstream commit 891cdbb162ccdb079cd5228ae43bdeebce8597ad ]
    
    nvme_fc_unregister_remote removes the remote port on a lport object at
    any point in time when there is no active association. This races with
    with the reconnect logic, because nvme_fc_create_association is not
    taking a lock to check the port_state and atomically increase the
    active count on the rport.
    
    Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Closes: https://lore.kernel.org/all/u4ttvhnn7lark5w3sgrbuy2rxupcvosp4qmvj46nwzgeo5ausc@uyrkdls2muwx
    Signed-off-by: Daniel Wagner <wagi@kernel.org>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01e7f84984ceadc63074f7b7d566a6be68aeddbf
Author: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
Date:   Thu Sep 11 21:07:42 2025 -0700

    tee: allow a driver to allocate a tee_device without a pool
    
    [ Upstream commit 6dbcd5a9ab6cb6644e7d728521da1c9035ec7235 ]
    
    A TEE driver doesn't always need to provide a pool if it doesn't
    support memory sharing ioctls and can allocate memory for TEE
    messages in another way. Although this is mentioned in the
    documentation for tee_device_alloc(), it is not handled correctly.
    
    Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
    Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
    Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31465df02736926e2ad79af76bf6af2d1a18c6ab
Author: Hans de Goede <hansg@kernel.org>
Date:   Fri Sep 12 22:00:17 2025 +0200

    ACPICA: dispatcher: Use acpi_ds_clear_operands() in acpi_ds_call_control_method()
    
    [ Upstream commit e9dff11a7a50fcef23fe3e8314fafae6d5641826 ]
    
    When deleting the previous walkstate operand stack
    acpi_ds_call_control_method() was deleting obj_desc->Method.param_count
    operands. But Method.param_count does not necessarily match
    this_walk_state->num_operands, it may be either less or more.
    
    After correcting the for loop to check `i < this_walk_state->num_operands`
    the code is identical to acpi_ds_clear_operands(), so just outright
    replace the code with acpi_ds_clear_operands() to fix this.
    
    Link: https://github.com/acpica/acpica/commit/53fc0220
    Signed-off-by: Hans de Goede <hansg@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 772a509d1380fda1b870ebd19da55057d71e7948
Author: Sarthak Garg <quic_sartgarg@quicinc.com>
Date:   Mon Sep 8 16:11:19 2025 +0530

    mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card
    
    [ Upstream commit 08b68ca543ee9d5a8d2dc406165e4887dd8f170b ]
    
    For Qualcomm SoCs which needs level shifter for SD card, extra delay is
    seen on receiver data path.
    
    To compensate this delay enable tuning for SDR50 mode for targets which
    has level shifter. SDHCI_SDR50_NEEDS_TUNING caps will be set for targets
    with level shifter on Qualcomm SOC's.
    
    Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a9a012f64d3cff98be0cf87831341932347f078
Author: Christian Bruel <christian.bruel@foss.st.com>
Date:   Tue Sep 2 11:10:45 2025 +0200

    irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment
    
    [ Upstream commit 2ef3886ce626dcdab0cbc452dbbebc19f57133d8 ]
    
    The PCI Local Bus Specification 3.0 (section 6.8.1.6) allows modifying the
    low-order bits of the MSI Message DATA register to encode nr_irqs interrupt
    numbers in the log2(nr_irqs) bits for the domain.
    
    The problem arises if the base vector (GICV2m base spi) is not aligned with
    nr_irqs; in this case, the low-order log2(nr_irqs) bits from the base
    vector conflict with the nr_irqs masking, causing the wrong MSI interrupt
    to be identified.
    
    To fix this, use bitmap_find_next_zero_area_off() instead of
    bitmap_find_free_region() to align the initial base vector with nr_irqs.
    
    Signed-off-by: Christian Bruel <christian.bruel@foss.st.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/all/20250902091045.220847-1-christian.bruel@foss.st.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bf876ed02ff671ddf47f59f2c20bcd7ba15564d
Author: Kees Cook <kees@kernel.org>
Date:   Sat Aug 30 19:23:53 2025 -0700

    arc: Fix __fls() const-foldability via __builtin_clzl()
    
    [ Upstream commit a3fecb9160482367365cc384c59dd220b162b066 ]
    
    While tracking down a problem where constant expressions used by
    BUILD_BUG_ON() suddenly stopped working[1], we found that an added static
    initializer was convincing the compiler that it couldn't track the state
    of the prior statically initialized value. Tracing this down found that
    ffs() was used in the initializer macro, but since it wasn't marked with
    __attribute__const__, the compiler had to assume the function might
    change variable states as a side-effect (which is not true for ffs(),
    which provides deterministic math results).
    
    For arc architecture with CONFIG_ISA_ARCV2=y, the __fls() function
    uses __builtin_arc_fls() which lacks GCC's const attribute, preventing
    compile-time constant folding, and KUnit testing of ffs/fls fails on
    arc[3]. A patch[2] to GCC to solve this has been sent.
    
    Add a fix for this by handling compile-time constants with the standard
    __builtin_clzl() builtin (which has const attribute) while preserving
    the optimized arc-specific builtin for runtime cases. This has the added
    benefit of skipping runtime calculation of compile-time constant values.
    Even with the GCC bug fixed (which is about "attribute const") this is a
    good change to avoid needless runtime costs, and should be done
    regardless of the state of GCC's bug.
    
    Build tested ARCH=arc allyesconfig with GCC arc-linux 15.2.0.
    
    Link: https://github.com/KSPP/linux/issues/364 [1]
    Link: https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693273.html
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202508031025.doWxtzzc-lkp@intel.com/ [3]
    Signed-off-by: Kees Cook <kees@kernel.org>
    Acked-by: Vineet Gupta <vgupta@kernel.org>
    Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 956b56d17a89775e4957bbddefa45cd3c6c71000
Author: Dennis Beier <nanovim@gmail.com>
Date:   Sat Aug 30 16:43:59 2025 +0200

    cpufreq/longhaul: handle NULL policy in longhaul_exit
    
    [ Upstream commit 592532a77b736b5153e0c2e4c74aa50af0a352ab ]
    
    longhaul_exit() was calling cpufreq_cpu_get(0) without checking
    for a NULL policy pointer. On some systems, this could lead to a
    NULL dereference and a kernel warning or panic.
    
    This patch adds a check using unlikely() and returns early if the
    policy is NULL.
    
    Bugzilla: #219962
    
    Signed-off-by: Dennis Beier <nanovim@gmail.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f52d3db6d95a06148665d5ad20d94b6b47d7cba8
Author: Ricardo B. Marlière <rbm@suse.com>
Date:   Thu Aug 28 10:12:33 2025 -0300

    selftests/bpf: Fix bpf_prog_detach2 usage in test_lirc_mode2
    
    [ Upstream commit 98857d111c53954aa038fcbc4cf48873e4240f7c ]
    
    Commit e9fc3ce99b34 ("libbpf: Streamline error reporting for high-level
    APIs") redefined the way that bpf_prog_detach2() returns. Therefore, adapt
    the usage in test_lirc_mode2_user.c.
    
    Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20250828-selftests-bpf-v1-1-c7811cd8b98c@suse.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1dfe36ef9b685b0ff84566393b14bd49adeb4704
Author: Mario Limonciello (AMD) <superm1@kernel.org>
Date:   Wed Aug 20 12:09:26 2025 -0500

    ACPI: video: force native for Lenovo 82K8
    
    [ Upstream commit f144bc21befdcf8e54d2f19b23b4e84f13be01f9 ]
    
    Lenovo 82K8 has a broken brightness control provided by nvidia_wmi_ec.
    Add a quirk to prevent using it.
    
    Reported-by: Wilson Alvarez <wilson.e.alvarez@rubonnek.com>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4512
    Tested-by: Wilson Alvarez <wilson.e.alvarez@rubonnek.com>
    Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
    Link: https://patch.msgid.link/20250820170927.895573-1-superm1@kernel.org
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8bb45e980b84aaf787774c4f75920972f2f1604b
Author: Jiayi Li <lijiayi@kylinos.cn>
Date:   Mon Aug 4 10:48:25 2025 +0800

    memstick: Add timeout to prevent indefinite waiting
    
    [ Upstream commit b65e630a55a490a0269ab1e4a282af975848064c ]
    
    Add timeout handling to wait_for_completion calls in memstick_set_rw_addr()
    and memstick_alloc_card() to prevent indefinite blocking in case of
    hardware or communication failures.
    
    Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
    Link: https://lore.kernel.org/r/20250804024825.1565078-1-lijiayi@kylinos.cn
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9ba193dd0e1b515bd12088c5e37a22f0e4ade8f
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Sun Jun 29 21:38:56 2025 +0100

    mmc: host: renesas_sdhi: Fix the actual clock
    
    [ Upstream commit 9c174e4dacee9fb2014a4ffc953d79a5707b77e4 ]
    
    Wrong actual clock reported, if the SD clock division ratio is other
    than 1:1(bits DIV[7:0] in SD_CLK_CTRL are set to 11111111).
    
    On high speed mode, cat /sys/kernel/debug/mmc1/ios
    Without the patch:
    clock:          50000000 Hz
    actual clock:   200000000 Hz
    
    After the fix:
    clock:          50000000 Hz
    actual clock:   50000000 Hz
    
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Link: https://lore.kernel.org/r/20250629203859.170850-1-biju.das.jz@bp.renesas.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a795950d17ece89b6d7e67a521d931b4a8d867e
Author: Chi Zhang <chizhang@asrmicro.com>
Date:   Thu Aug 7 14:20:38 2025 +0800

    pinctrl: single: fix bias pull up/down handling in pin_config_set
    
    [ Upstream commit 236152dd9b1675a35eee912e79e6c57ca6b6732f ]
    
    In the pin_config_set function, when handling PIN_CONFIG_BIAS_PULL_DOWN or
    PIN_CONFIG_BIAS_PULL_UP, the function calls pcs_pinconf_clear_bias()
    which writes the register. However, the subsequent operations continue
    using the stale 'data' value from before the register write, effectively
    causing the bias clear operation to be overwritten and not take effect.
    
    Fix this by reading the 'data' value from the register after calling
    pcs_pinconf_clear_bias().
    
    This bug seems to have existed when this code was first merged in commit
    9dddb4df90d1 ("pinctrl: single: support generic pinconf").
    
    Signed-off-by: Chi Zhang <chizhang@asrmicro.com>
    Link: https://lore.kernel.org/20250807062038.13610-1-chizhang@asrmicro.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09896bf6fe1a3e0db1aaf8b08024bcdf920710c8
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Date:   Mon Aug 11 14:08:04 2025 +0200

    bpf: Don't use %pK through printk
    
    [ Upstream commit 2caa6b88e0ba0231fb4ff0ba8e73cedd5fb81fc8 ]
    
    In the past %pK was preferable to %p as it would not leak raw pointer
    values into the kernel log.
    Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
    the regular %p has been improved to avoid this issue.
    Furthermore, restricted pointers ("%pK") were never meant to be used
    through printk(). They can still unintentionally leak raw pointers or
    acquire sleeping locks in atomic contexts.
    
    Switch to the regular pointer formatting which is safer and
    easier to reason about.
    
    Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20250811-restricted-pointers-bpf-v1-1-a1d7cc3cb9e7@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af0fc5a59e920071af8f939d94add3479e85b9a4
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Date:   Mon Aug 11 09:48:30 2025 +0200

    soc: ti: pruss: don't use %pK through printk
    
    [ Upstream commit a5039648f86424885aae37f03dc39bc9cb972ecb ]
    
    In the past %pK was preferable to %p as it would not leak raw pointer
    values into the kernel log.
    Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
    the regular %p has been improved to avoid this issue.
    Furthermore, restricted pointers ("%pK") were never meant to be used
    through printk(). They can still unintentionally leak raw pointers or
    acquire sleeping locks in atomic contexts.
    
    Switch to the regular pointer formatting which is safer and
    easier to reason about.
    
    Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
    Link: https://lore.kernel.org/r/20250811-restricted-pointers-soc-v2-1-7af7ed993546@linutronix.de
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 487cbcdec516e5ef9dfb096bd1ca66b2689710e3
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Date:   Mon Aug 11 14:10:21 2025 +0200

    spi: loopback-test: Don't use %pK through printk
    
    [ Upstream commit b832b19318534bb4f1673b24d78037fee339c679 ]
    
    In the past %pK was preferable to %p as it would not leak raw pointer
    values into the kernel log.
    Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
    the regular %p has been improved to avoid this issue.
    Furthermore, restricted pointers ("%pK") were never meant to be used
    through printk(). They can still unintentionally leak raw pointers or
    acquire sleeping locks in atomic contexts.
    
    Switch to the regular pointer formatting which is safer and
    easier to reason about.
    There are still a few users of %pK left, but these use it through seq_file,
    for which its usage is safe.
    
    Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
    Link: https://patch.msgid.link/20250811-restricted-pointers-spi-v1-1-32c47f954e4d@linutronix.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0987ad26205ce2e769b36a43868c086bd4c9cb73
Author: Jens Reidel <adrian@mainlining.org>
Date:   Sun Jul 27 01:56:46 2025 +0200

    soc: qcom: smem: Fix endian-unaware access of num_entries
    
    [ Upstream commit 19e7aa0e9e46d0ad111a4af55b3d681b6ad945e0 ]
    
    Add a missing le32_to_cpu when accessing num_entries, which is always a
    little endian integer.
    
    Fixes booting on Xiaomi Mi 9T (xiaomi-davinci) in big endian.
    
    Signed-off-by: Jens Reidel <adrian@mainlining.org>
    Link: https://lore.kernel.org/r/20250726235646.254730-1-adrian@mainlining.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efe9a9e6f46adcdffc51ae6aa61e62aa10a5ce73
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Mon Nov 3 09:59:16 2025 -0500

    block: make REQ_OP_ZONE_OPEN a write operation
    
    [ Upstream commit 19de03b312d69a7e9bacb51c806c6e3f4207376c ]
    
    A REQ_OP_OPEN_ZONE request changes the condition of a sequential zone of
    a zoned block device to the explicitly open condition
    (BLK_ZONE_COND_EXP_OPEN). As such, it should be considered a write
    operation.
    
    Change this operation code to be an odd number to reflect this. The
    following operation numbers are changed to keep the numbering compact.
    
    No problems were reported without this change as this operation has no
    data. However, this unifies the zone operation to reflect that they
    modify the device state and also allows strengthening checks in the
    block layer, e.g. checking if this operation is not issued against a
    read-only device.
    
    Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    [ relocated REQ_OP_ZONE_APPEND from 15 to 21 to resolve numbering conflict ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c0dbd240be3f87cac321b14e17979b7e9cb6a8f
Author: Owen Gu <guhuinan@xiaomi.com>
Date:   Mon Sep 15 17:29:07 2025 +0800

    usb: gadget: f_fs: Fix epfile null pointer access after ep enable.
    
    commit cfd6f1a7b42f62523c96d9703ef32b0dbc495ba4 upstream.
    
    A race condition occurs when ffs_func_eps_enable() runs concurrently
    with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()
    sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading
    to a NULL pointer dereference when accessing epfile->ep in
    ffs_func_eps_enable() after successful usb_ep_enable().
    
    The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and
    ffs_data_close() functions, and its modification is protected by the
    spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function
    is also protected by ffs->eps_lock.
    
    Thus, add NULL pointer handling for ffs->epfiles in the
    ffs_func_eps_enable() function to fix issues
    
    Signed-off-by: Owen Gu <guhuinan@xiaomi.com>
    Link: https://lore.kernel.org/r/20250915092907.17802-1-guhuinan@xiaomi.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd39e0e953beadfab29d0c0c06c096a8e5c18581
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Oct 17 18:53:27 2025 +0200

    tracing: fix declaration-after-statement warning
    
    When building this kernel version this warning is visible:
    
      kernel/trace/trace_events_synth.c: In function 'synth_event_reg':
      kernel/trace/trace_events_synth.c:847:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
        847 |         int ret = trace_event_reg(call, type, data);
            |         ^~~
    
    This can be easily fixed by declaring 'ret' earlier.
    
    This issue is visible in < v5.18, because -std=gnu89 is used by default,
    see commit e8c07082a810 ("Kbuild: move to -std=gnu11").
    
    Please note that in v5.15.y, the 'Fixes' commit has been modified during
    the backport, not to have this warning. See commit 72848b81b3dd
    ("tracing: Ensure module defining synth event cannot be unloaded while
    tracing") from v5.15.y.
    
    Fixes: 21581dd4e7ff ("tracing: Ensure module defining synth event cannot be unloaded while tracing")
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Cc: Douglas Raillard <douglas.raillard@arm.com>
    Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04ce0aa282ffc73e1479f889b57bd79cfc288a6e
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri Oct 17 18:53:26 2025 +0200

    arch: back to -std=gnu89 in < v5.18
    
    Recent fixes have been backported to < v5.18 to fix build issues with
    GCC 5.15. They all force -std=gnu11 in the CFLAGS, "because [the kernel]
    requests the gnu11 standard via '-std=' in the main Makefile".
    
    This is true for >= 5.18 versions, but not before. This switch to
    -std=gnu11 has been done in commit e8c07082a810 ("Kbuild: move to
    -std=gnu11").
    
    For a question of uniformity, force -std=gnu89, similar to what is done
    in the main Makefile.
    
    Note: the fixes tags below refers to upstream commits, but this fix is
    only for kernels not having commit e8c07082a810 ("Kbuild: move to
    -std=gnu11").
    
    Fixes: 7cbb015e2d3d ("parisc: fix building with gcc-15")
    Fixes: 3b8b80e99376 ("s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS")
    Fixes: b3bee1e7c3f2 ("x86/boot: Compile boot code with -std=gnu11 too")
    Fixes: ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15")
    Fixes: 8ba14d9f490a ("efi: libstub: Use '-std=gnu11' to fix build with GCC 15")
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d226e837569669812bed0131bec3f47d6eb90d5
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Fri Oct 17 18:53:25 2025 +0200

    x86/boot: Compile boot code with -std=gnu11 too
    
    commit b3bee1e7c3f2b1b77182302c7b2131c804175870 upstream.
    
    Use -std=gnu11 for consistency with main kernel code.
    
    It doesn't seem to change anything in vmlinux.
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
    Link: https://lore.kernel.org/r/2058761e-12a4-4b2f-9690-3c3c1c9902a5@p183
    [ This kernel version doesn't build with GCC 15:
    
        In file included from include/uapi/linux/posix_types.h:5,
                         from include/uapi/linux/types.h:14,
                         from include/linux/types.h:6,
                         from arch/x86/realmode/rm/wakeup.h:11,
                         from arch/x86/realmode/rm/wakemain.c:2:
        include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
           11 |         false   = 0,
              |         ^~~~~
        include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
        include/linux/types.h:30:33: error: 'bool' cannot be defined via 'typedef'
           30 | typedef _Bool                   bool;
              |                                 ^~~~
        include/linux/types.h:30:33: note: 'bool' is a keyword with '-std=c23' onwards
        include/linux/types.h:30:1: warning: useless type name in empty declaration
           30 | typedef _Bool                   bool;
              | ^~~~~~~
    
      The fix is similar to commit ee2ab467bddf ("x86/boot: Use '-std=gnu11'
      to fix build with GCC 15") which has been backported to this kernel.
    
      Note: In < 5.18 version, -std=gnu89 is used instead of -std=gnu11, see
      commit e8c07082a810 ("Kbuild: move to -std=gnu11"). I suggest not to
      modify that in this commit here as all the other similar fixes to
      support GCC 15 set -std=gnu11. This can be done in a dedicated commit
      if needed.
      There was a conflict, because commit 2838307b019d ("x86/build: Remove
      -m16 workaround for unsupported versions of GCC") is not in this
      version and change code in the context. -std=gnu11 can still be added
      at the same place. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a3643dda9fa4c585af63cc11bea308103d24d2f
Author: Babu Moger <babu.moger@amd.com>
Date:   Tue Oct 28 13:25:14 2025 -0500

    x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID
    
    [ Upstream commit 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 ]
    
    Users can create as many monitoring groups as the number of RMIDs supported
    by the hardware. However, on AMD systems, only a limited number of RMIDs
    are guaranteed to be actively tracked by the hardware. RMIDs that exceed
    this limit are placed in an "Unavailable" state.
    
    When a bandwidth counter is read for such an RMID, the hardware sets
    MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked
    again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable
    remains set on first read after tracking re-starts and is clear on all
    subsequent reads as long as the RMID is tracked.
    
    resctrl miscounts the bandwidth events after an RMID transitions from the
    "Unavailable" state back to being tracked. This happens because when the
    hardware starts counting again after resetting the counter to zero, resctrl
    in turn compares the new count against the counter value stored from the
    previous time the RMID was tracked.
    
    This results in resctrl computing an event value that is either undercounting
    (when new counter is more than stored counter) or a mistaken overflow (when
    new counter is less than stored counter).
    
    Reset the stored value (arch_mbm_state::prev_msr) of MSR_IA32_QM_CTR to
    zero whenever the RMID is in the "Unavailable" state to ensure accurate
    counting after the RMID resets to zero when it starts to be tracked again.
    
    Example scenario that results in mistaken overflow
    ==================================================
    1. The resctrl filesystem is mounted, and a task is assigned to a
       monitoring group.
    
       $mount -t resctrl resctrl /sys/fs/resctrl
       $mkdir /sys/fs/resctrl/mon_groups/test1/
       $echo 1234 > /sys/fs/resctrl/mon_groups/test1/tasks
    
       $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
       21323            <- Total bytes on domain 0
       "Unavailable"    <- Total bytes on domain 1
    
       Task is running on domain 0. Counter on domain 1 is "Unavailable".
    
    2. The task runs on domain 0 for a while and then moves to domain 1. The
       counter starts incrementing on domain 1.
    
       $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
       7345357          <- Total bytes on domain 0
       4545             <- Total bytes on domain 1
    
    3. At some point, the RMID in domain 0 transitions to the "Unavailable"
       state because the task is no longer executing in that domain.
    
       $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
       "Unavailable"    <- Total bytes on domain 0
       434341           <- Total bytes on domain 1
    
    4.  Since the task continues to migrate between domains, it may eventually
        return to domain 0.
    
        $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes
        17592178699059  <- Overflow on domain 0
        3232332         <- Total bytes on domain 1
    
    In this case, the RMID on domain 0 transitions from "Unavailable" state to
    active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when
    the counter is read and begins tracking the RMID counting from 0.
    
    Subsequent reads succeed but return a value smaller than the previously
    saved MSR value (7345357). Consequently, the resctrl's overflow logic is
    triggered, it compares the previous value (7345357) with the new, smaller
    value and incorrectly interprets this as a counter overflow, adding a large
    delta.
    
    In reality, this is a false positive: the counter did not overflow but was
    simply reset when the RMID transitioned from "Unavailable" back to active
    state.
    
    Here is the text from APM [1] available from [2].
    
    "In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the
    first QM_CTR read when it begins tracking an RMID that it was not
    previously tracking. The U bit will be zero for all subsequent reads from
    that RMID while it is still tracked by the hardware. Therefore, a QM_CTR
    read with the U bit set when that RMID is in use by a processor can be
    considered 0 when calculating the difference with a subsequent read."
    
    [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming
        Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory
        Bandwidth (MBM).
    
      [ bp: Split commit message into smaller paragraph chunks for better
        consumption. ]
    
    Fixes: 4d05bf71f157d ("x86/resctrl: Introduce AMD QOS feature")
    Signed-off-by: Babu Moger <babu.moger@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Tested-by: Reinette Chatre <reinette.chatre@intel.com>
    Cc: stable@vger.kernel.org # needs adjustments for <= v6.17
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2]
    (cherry picked from commit 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92)
    [babu.moger@amd.com: Needed backport for v5.10 stable]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5075acbe07a1c0ab6cead25ccc4eeda6ee4325be
Author: Artem Shimko <a.shimko.dev@gmail.com>
Date:   Mon Oct 27 14:42:49 2025 -0400

    serial: 8250_dw: handle reset control deassert error
    
    [ Upstream commit daeb4037adf7d3349b4a1fb792f4bc9824686a4b ]
    
    Check the return value of reset_control_deassert() in the probe
    function to prevent continuing probe when reset deassertion fails.
    
    Previously, reset_control_deassert() was called without checking its
    return value, which could lead to probe continuing even when the
    device reset wasn't properly deasserted.
    
    The fix checks the return value and returns an error with dev_err_probe()
    if reset deassertion fails, providing better error handling and
    diagnostics.
    
    Fixes: acbdad8dd1ab ("serial: 8250_dw: simplify optional reset handling")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Artem Shimko <a.shimko.dev@gmail.com>
    Link: https://patch.msgid.link/20251019095131.252848-1-a.shimko.dev@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 579aaad695e04277bf0e3911c88cddecd3cdd400
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Oct 27 14:42:48 2025 -0400

    serial: 8250_dw: Use devm_add_action_or_reset()
    
    [ Upstream commit 295b09128d12fb1a7a67f771cc0ae0df869eafaf ]
    
    Slightly simplify ->probe() and drop a few goto labels by using
    devm_add_action_or_reset() for clock and reset cleanup.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20220509172129.37770-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: daeb4037adf7 ("serial: 8250_dw: handle reset control deassert error")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b26180248b5052c1cac9f0bcb2282035cf013e5f
Author: Celeste Liu <uwu@coelacanthus.name>
Date:   Mon Oct 27 20:55:39 2025 +0800

    can: gs_usb: increase max interface to U8_MAX
    
    commit 2a27f6a8fb5722223d526843040f747e9b0e8060 upstream
    
    This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD
    converter[1]. The original developers may have only 3 interfaces
    device to test so they write 3 here and wait for future change.
    
    During the HSCanT development, we actually used 4 interfaces, so the
    limitation of 3 is not enough now. But just increase one is not
    future-proofed. Since the channel index type in gs_host_frame is u8,
    just make canch[] become a flexible array with a u8 index, so it
    naturally constraint by U8_MAX and avoid statically allocate 256
    pointer for every gs_usb device.
    
    [1]: https://github.com/cherry-embedded/HSCanT-hardware
    
    Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
    Reported-by: Runcheng Lu <runcheng.lu@hpmicro.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Vincent Mailhol <mailhol@kernel.org>
    Signed-off-by: Celeste Liu <uwu@coelacanthus.name>
    Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacanthus.name
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a113d66a8ccbf3d81ccda51c682f5ad52391c55f
Author: Maarten Lankhorst <dev@lankhorst.se>
Date:   Mon Oct 27 09:49:17 2025 -0400

    devcoredump: Fix circular locking dependency with devcd->mutex.
    
    [ Upstream commit a91c8096590bd7801a26454789f2992094fe36da ]
    
    The original code causes a circular locking dependency found by lockdep.
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S   U
    ------------------------------------------------------
    xe_fault_inject/5091 is trying to acquire lock:
    ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660
    
    but task is already holding lock:
    
    ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0
    which lock already depends on the new lock.
    the existing dependency chain (in reverse order) is:
    -> #2 (&devcd->mutex){+.+.}-{3:3}:
           mutex_lock_nested+0x4e/0xc0
           devcd_data_write+0x27/0x90
           sysfs_kf_bin_write+0x80/0xf0
           kernfs_fop_write_iter+0x169/0x220
           vfs_write+0x293/0x560
           ksys_write+0x72/0xf0
           __x64_sys_write+0x19/0x30
           x64_sys_call+0x2bf/0x2660
           do_syscall_64+0x93/0xb60
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    -> #1 (kn->active#236){++++}-{0:0}:
           kernfs_drain+0x1e2/0x200
           __kernfs_remove+0xae/0x400
           kernfs_remove_by_name_ns+0x5d/0xc0
           remove_files+0x54/0x70
           sysfs_remove_group+0x3d/0xa0
           sysfs_remove_groups+0x2e/0x60
           device_remove_attrs+0xc7/0x100
           device_del+0x15d/0x3b0
           devcd_del+0x19/0x30
           process_one_work+0x22b/0x6f0
           worker_thread+0x1e8/0x3d0
           kthread+0x11c/0x250
           ret_from_fork+0x26c/0x2e0
           ret_from_fork_asm+0x1a/0x30
    -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}:
           __lock_acquire+0x1661/0x2860
           lock_acquire+0xc4/0x2f0
           __flush_work+0x27a/0x660
           flush_delayed_work+0x5d/0xa0
           dev_coredump_put+0x63/0xa0
           xe_driver_devcoredump_fini+0x12/0x20 [xe]
           devm_action_release+0x12/0x30
           release_nodes+0x3a/0x120
           devres_release_all+0x8a/0xd0
           device_unbind_cleanup+0x12/0x80
           device_release_driver_internal+0x23a/0x280
           device_driver_detach+0x14/0x20
           unbind_store+0xaf/0xc0
           drv_attr_store+0x21/0x50
           sysfs_kf_write+0x4a/0x80
           kernfs_fop_write_iter+0x169/0x220
           vfs_write+0x293/0x560
           ksys_write+0x72/0xf0
           __x64_sys_write+0x19/0x30
           x64_sys_call+0x2bf/0x2660
           do_syscall_64+0x93/0xb60
           entry_SYSCALL_64_after_hwframe+0x76/0x7e
    other info that might help us debug this:
    Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex
     Possible unsafe locking scenario:
           CPU0                    CPU1
           ----                    ----
      lock(&devcd->mutex);
                                   lock(kn->active#236);
                                   lock(&devcd->mutex);
      lock((work_completion)(&(&devcd->del_wk)->work));
     *** DEADLOCK ***
    5 locks held by xe_fault_inject/5091:
     #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0
     #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220
     #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280
     #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0
     #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660
    stack backtrace:
    CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S   U              6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)}
    Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
    Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021
    Call Trace:
     <TASK>
     dump_stack_lvl+0x91/0xf0
     dump_stack+0x10/0x20
     print_circular_bug+0x285/0x360
     check_noncircular+0x135/0x150
     ? register_lock_class+0x48/0x4a0
     __lock_acquire+0x1661/0x2860
     lock_acquire+0xc4/0x2f0
     ? __flush_work+0x25d/0x660
     ? mark_held_locks+0x46/0x90
     ? __flush_work+0x25d/0x660
     __flush_work+0x27a/0x660
     ? __flush_work+0x25d/0x660
     ? trace_hardirqs_on+0x1e/0xd0
     ? __pfx_wq_barrier_func+0x10/0x10
     flush_delayed_work+0x5d/0xa0
     dev_coredump_put+0x63/0xa0
     xe_driver_devcoredump_fini+0x12/0x20 [xe]
     devm_action_release+0x12/0x30
     release_nodes+0x3a/0x120
     devres_release_all+0x8a/0xd0
     device_unbind_cleanup+0x12/0x80
     device_release_driver_internal+0x23a/0x280
     ? bus_find_device+0xa8/0xe0
     device_driver_detach+0x14/0x20
     unbind_store+0xaf/0xc0
     drv_attr_store+0x21/0x50
     sysfs_kf_write+0x4a/0x80
     kernfs_fop_write_iter+0x169/0x220
     vfs_write+0x293/0x560
     ksys_write+0x72/0xf0
     __x64_sys_write+0x19/0x30
     x64_sys_call+0x2bf/0x2660
     do_syscall_64+0x93/0xb60
     ? __f_unlock_pos+0x15/0x20
     ? __x64_sys_getdents64+0x9b/0x130
     ? __pfx_filldir64+0x10/0x10
     ? do_syscall_64+0x1a2/0xb60
     ? clear_bhb_loop+0x30/0x80
     ? clear_bhb_loop+0x30/0x80
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    RIP: 0033:0x76e292edd574
    Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
    RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574
    RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b
    RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063
    R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000
     </TASK>
    xe 0000:03:00.0: [drm] Xe device coredump has been deleted.
    
    Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work")
    Cc: Mukesh Ojha <quic_mojha@quicinc.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Cc: Rafael J. Wysocki <rafael@kernel.org>
    Cc: Danilo Krummrich <dakr@kernel.org>
    Cc: linux-kernel@vger.kernel.org
    Cc: stable@vger.kernel.org # v6.1+
    Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
    Cc: Matthew Brost <matthew.brost@intel.com>
    Acked-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [ replaced disable_delayed_work_sync() with cancel_delayed_work_sync() ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fb2f53c499e161714a68227d04d4aa019407804
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Mon Oct 27 09:49:57 2025 -0400

    xfs: always warn about deprecated mount options
    
    [ Upstream commit 630785bfbe12c3ee3ebccd8b530a98d632b7e39d ]
    
    The deprecation of the 'attr2' mount option in 6.18 wasn't entirely
    successful because nobody noticed that the kernel never printed a
    warning about attr2 being set in fstab if the only xfs filesystem is the
    root fs; the initramfs mounts the root fs with no mount options; and the
    init scripts only conveyed the fstab options by remounting the root fs.
    
    Fix this by making it complain all the time.
    
    Cc: stable@vger.kernel.org # v5.13
    Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options")
    Signed-off-by: Darrick J. Wong <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
    Signed-off-by: Carlos Maiolino <cem@kernel.org>
    [ adapted m_features field reference to m_flags ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0791e6870523e728819f92f29e4b7f162395a0b7
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Mon Oct 27 10:40:08 2025 -0400

    net: ravb: Enforce descriptor type ordering
    
    [ Upstream commit 5370c31e84b0e0999c7b5ff949f4e104def35584 ]
    
    Ensure the TX descriptor type fields are published in a safe order so the
    DMA engine never begins processing a descriptor chain before all descriptor
    fields are fully initialised.
    
    For multi-descriptor transmits the driver writes DT_FEND into the last
    descriptor and DT_FSTART into the first. The DMA engine begins processing
    when it observes DT_FSTART. Move the dma_wmb() barrier so it executes
    immediately after DT_FEND and immediately before writing DT_FSTART
    (and before DT_FSINGLE in the single-descriptor case). This guarantees
    that all prior CPU writes to the descriptor memory are visible to the
    device before DT_FSTART is seen.
    
    This avoids a situation where compiler/CPU reordering could publish
    DT_FSTART ahead of DT_FEND or other descriptor fields, allowing the DMA to
    start on a partially initialised chain and causing corrupted transmissions
    or TX timeouts. Such a failure was observed on RZ/G2L with an RT kernel as
    transmit queue timeouts and device resets.
    
    Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
    Cc: stable@vger.kernel.org
    Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
    Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Link: https://patch.msgid.link/20251017151830.171062-4-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ kept unconditional skb_tx_timestamp() ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad36e207ae28fef7f2d4541e904ced534287a597
Author: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Date:   Sun Nov 2 15:39:09 2025 -0500

    net: phy: dp83867: Disable EEE support as not implemented
    
    [ Upstream commit 84a905290cb4c3d9a71a9e3b2f2e02e031e7512f ]
    
    While the DP83867 PHYs report EEE capability through their feature
    registers, the actual hardware does not support EEE (see Links).
    When the connected MAC enables EEE, it causes link instability and
    communication failures.
    
    The issue is reproducible with a iMX8MP and relevant stmmac ethernet port.
    Since the introduction of phylink-managed EEE support in the stmmac driver,
    EEE is now enabled by default, leading to issues on systems using the
    DP83867 PHY.
    
    Call phy_disable_eee during phy initialization to prevent EEE from being
    enabled on DP83867 PHYs.
    
    Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1445244/dp83867ir-dp83867-disable-eee-lpi
    Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/658638/dp83867ir-eee-energy-efficient-ethernet
    Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy")
    Cc: stable@vger.kernel.org
    Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20251023144857.529566-1-ghidoliemanuele@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ replaced phy_disable_eee() call with direct eee_broken_modes assignment ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02d3041caaa3fe4dd69e5a8afd1ac6b918ddc6a1
Author: Alexey Klimov <alexey.klimov@linaro.org>
Date:   Wed Oct 22 21:10:12 2025 +0100

    regmap: slimbus: fix bus_context pointer in regmap init calls
    
    commit 434f7349a1f00618a620b316f091bd13a12bc8d2 upstream.
    
    Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in
    wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.
    That commit breaks audio playback, for instance, on sdm845 Thundercomm
    Dragonboard 845c board:
    
     Unable to handle kernel paging request at virtual address ffff8000847cbad4
     ...
     CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT
     Hardware name: Thundercomm Dragonboard 845c (DT)
     ...
     Call trace:
      slim_xfer_msg+0x24/0x1ac [slimbus] (P)
      slim_read+0x48/0x74 [slimbus]
      regmap_slimbus_read+0x18/0x24 [regmap_slimbus]
      _regmap_raw_read+0xe8/0x174
      _regmap_bus_read+0x44/0x80
      _regmap_read+0x60/0xd8
      _regmap_update_bits+0xf4/0x140
      _regmap_select_page+0xa8/0x124
      _regmap_raw_write_impl+0x3b8/0x65c
      _regmap_bus_raw_write+0x60/0x80
      _regmap_write+0x58/0xc0
      regmap_write+0x4c/0x80
      wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x]
      snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core]
      __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core]
      dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core]
      dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core]
      snd_pcm_hw_params+0x124/0x464 [snd_pcm]
      snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm]
      snd_pcm_ioctl+0x34/0x4c [snd_pcm]
      __arm64_sys_ioctl+0xac/0x104
      invoke_syscall+0x48/0x104
      el0_svc_common.constprop.0+0x40/0xe0
      do_el0_svc+0x1c/0x28
      el0_svc+0x34/0xec
      el0t_64_sync_handler+0xa0/0xf0
      el0t_64_sync+0x198/0x19c
    
    The __devm_regmap_init_slimbus() started to be used instead of
    __regmap_init_slimbus() after the commit mentioned above and turns out
    the incorrect bus_context pointer (3rd argument) was used in
    __devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal
    to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or
    the first user of devm_regmap_init_slimbus() but we should fix it till
    the point where __devm_regmap_init_slimbus() was introduced therefore
    two "Fixes" tags.
    
    While at this, also correct the same argument in __regmap_init_slimbus().
    
    Fixes: 4e65bda8273c ("ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()")
    Fixes: 7d6f7fb053ad ("regmap: add SLIMbus support")
    Cc: stable@vger.kernel.org
    Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Cc: Ma Ke <make24@iscas.ac.cn>
    Cc: Steev Klimaszewski <steev@kali.org>
    Cc: Srinivas Kandagatla <srini@kernel.org>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Link: https://patch.msgid.link/20251022201013.1740211-1-alexey.klimov@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4cd7fe3813f90643ed8bee090b00770cc877babe
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Mon Oct 27 09:27:32 2025 +0900

    block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL
    
    commit 12a1c9353c47c0fb3464eba2d78cdf649dee1cf7 upstream.
    
    REQ_OP_ZONE_RESET_ALL is a zone management request. Fix
    op_is_zone_mgmt() to return true for that operation, like it already
    does for REQ_OP_ZONE_RESET.
    
    While no problems were reported without this fix, this change allows
    strengthening checks in various block device drivers (scsi sd,
    virtioblk, DM) where op_is_zone_mgmt() is used to verify that a zone
    management command is not being issued to a regular block device.
    
    Fixes: 6c1b1da58f8c ("block: add zone open, close and finish operations")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c5cfb85ba621f7dfca643ba5fb7bcf7104a28b8
Author: John Smith <itistotalbotnet@gmail.com>
Date:   Tue Oct 21 11:09:09 2025 +0200

    drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Iceland
    
    [ Upstream commit 501672e3c1576aa9a8364144213c77b98a31a42c ]
    
    Previously this was initialized with zero which represented PCIe Gen
    1.0 instead of using the
    maximum value from the speed table which is the behaviour of all other
    smumgr implementations.
    
    Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.")
    Signed-off-by: John Smith <itistotalbotnet@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 92b0a6ae6672857ddeabf892223943d2f0e06c97)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6dfdeb55b31145bb10659a26e5e67842617d591a
Author: John Smith <itistotalbotnet@gmail.com>
Date:   Tue Oct 21 11:08:13 2025 +0200

    drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji
    
    [ Upstream commit 07a13f913c291d6ec72ee4fc848d13ecfdc0e705 ]
    
    Previously this was initialized with zero which represented PCIe Gen
    1.0 instead of using the
    maximum value from the speed table which is the behaviour of all other
    smumgr implementations.
    
    Fixes: 18edef19ea44 ("drm/amd/powerplay: implement fw image related smu interface for Fiji.")
    Signed-off-by: John Smith <itistotalbotnet@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit c52238c9fb414555c68340cd80e487d982c1921c)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46b109ff5490cf75eb6ec5b0e2ead03738d5c3ba
Author: Yang Wang <kevinyang.wang@amd.com>
Date:   Wed Oct 22 14:12:21 2025 +0800

    drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table()
    
    [ Upstream commit 238d468d3ed18a324bb9d8c99f18c665dbac0511 ]
    
    'table_index' is a variable defined by the smu driver (kmd)
    'table_id' is a variable defined by the hw smu (pmfw)
    
    This code should use table_index as a bounds check.
    
    Fixes: caad2613dc4bd ("drm/amd/powerplay: move table setting common code to smu_cmn.c")
    Signed-off-by: Yang Wang <kevinyang.wang@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit fca0c66b22303de0d1d6313059baf4dc960a4753)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30529d0d5aad49102dc0365c21f81042a4b3998f
Author: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Date:   Tue Oct 21 11:37:23 2025 +0200

    drm/etnaviv: fix flush sequence logic
    
    [ Upstream commit a042beac6e6f8ac1e923784cfff98b47cbabb185 ]
    
    The current logic uses the flush sequence from the current address
    space. This is harmless when deducing the flush requirements for the
    current submit, as either the incoming address space is the same one
    as the currently active one or we switch context, in which case the
    flush is unconditional.
    
    However, this sequence is also stored as the current flush sequence
    of the GPU. If we switch context the stored flush sequence will no
    longer belong to the currently active address space. This incoherency
    can then cause missed flushes, resulting in translation errors.
    
    Fixes: 27b67278e007 ("drm/etnaviv: rework MMU handling")
    Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
    Link: https://lore.kernel.org/r/20251021093723.3887980-1-l.stach@pengutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88a38b135d69f5db9024ff6527232f1b51be8915
Author: Lizhi Xu <lizhi.xu@windriver.com>
Date:   Wed Oct 22 10:40:07 2025 +0800

    usbnet: Prevents free active kevent
    
    [ Upstream commit 420c84c330d1688b8c764479e5738bbdbf0a33de ]
    
    The root cause of this issue are:
    1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);
    put the kevent work in global workqueue. However, the kevent has not yet
    been scheduled when the usbnet device is unregistered. Therefore, executing
    free_netdev() results in the "free active object (kevent)" error reported
    here.
    
    2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(),
    if the usbnet device is up, ndo_stop() is executed to cancel the kevent.
    However, because the device is not up, ndo_stop() is not executed.
    
    The solution to this problem is to cancel the kevent before executing
    free_netdev().
    
    Fixes: a69e617e533e ("usbnet: Fix linkwatch use-after-free on disconnect")
    Reported-by: Sam Sun <samsun1006219@gmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=8bfd7bcc98f7300afb84
    Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
    Link: https://patch.msgid.link/20251022024007.1831898-1-lizhi.xu@windriver.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47626748a2a00068dbbd5836d19076637b4e235b
Author: Noorain Eqbal <nooraineqbal@gmail.com>
Date:   Mon Oct 20 23:33:01 2025 +0530

    bpf: Sync pending IRQ work before freeing ring buffer
    
    [ Upstream commit 4e9077638301816a7d73fa1e1b4c1db4a7e3b59c ]
    
    Fix a race where irq_work can be queued in bpf_ringbuf_commit()
    but the ring buffer is freed before the work executes.
    In the syzbot reproducer, a BPF program attached to sched_switch
    triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer
    is freed before this work executes, the irq_work thread may accesses
    freed memory.
    Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work
    complete before freeing the buffer.
    
    Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it")
    Reported-by: syzbot+2617fc732430968b45d2@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=2617fc732430968b45d2
    Tested-by: syzbot+2617fc732430968b45d2@syzkaller.appspotmail.com
    Signed-off-by: Noorain Eqbal <nooraineqbal@gmail.com>
    Link: https://lore.kernel.org/r/20251020180301.103366-1-nooraineqbal@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 547539f08b9e3629ce68479889813e58c8087e70
Author: Roy Vegard Ovesen <roy.vegard.ovesen@gmail.com>
Date:   Sat Oct 18 19:18:22 2025 +0200

    ALSA: usb-audio: fix control pipe direction
    
    [ Upstream commit 7963891f7c9c6f759cc9ab7da71406b4234f3dd6 ]
    
    Since the requesttype has USB_DIR_OUT the pipe should be
    constructed with usb_sndctrlpipe().
    
    Fixes: 8dc5efe3d17c ("ALSA: usb-audio: Add support for Presonus Studio 1810c")
    Signed-off-by: Roy Vegard Ovesen <roy.vegard.ovesen@gmail.com>
    Link: https://patch.msgid.link/aPPL3tBFE_oU-JHv@ark
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6aad8747e20f7baa29647c625986fc12f6797faf
Author: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Date:   Thu Sep 11 02:14:05 2025 +0530

    drm/msm/a6xx: Fix GMU firmware parser
    
    [ Upstream commit b4789aac9d3441d9f830f0a4022d8dc122d6cab3 ]
    
    Current parser logic for GMU firmware assumes a dword aligned payload
    size for every block. This is not true for all GMU firmwares. So, fix
    this by using correct 'size' value in the calculation for the offset
    for the next block's header.
    
    Fixes: c6ed04f856a4 ("drm/msm/a6xx: A640/A650 GMU firmware path")
    Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
    Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Patchwork: https://patchwork.freedesktop.org/patch/674040/
    Message-ID: <20250911-assorted-sept-1-v2-2-a8bf1ee20792@oss.qualcomm.com>
    Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1d86341ea52887edc9a3bec7194611d6c49ad18
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>
Date:   Fri Sep 26 21:56:56 2025 +0200

    wifi: ath10k: Fix memory leak on unsupported WMI command
    
    [ Upstream commit 2e9c1da4ee9d0acfca2e0a3d78f3d8cb5802da1b ]
    
    ath10k_wmi_cmd_send takes ownership of the passed buffer (skb) and has the
    responsibility to release it in case of error. This patch fixes missing
    free in case of early error due to unhandled WMI command ID.
    
    Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1
    
    Fixes: 553215592f14 ("ath10k: warn if give WMI command is not supported")
    Suggested-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
    Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
    Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
    Link: https://patch.msgid.link/20250926195656.187970-1-loic.poulain@oss.qualcomm.com
    Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2225e285c6b0807819851f3b800600979969d8e
Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Date:   Fri Oct 17 09:52:56 2025 +0100

    ASoC: qdsp6: q6asm: do not sleep while atomic
    
    commit fdbb53d318aa94a094434e5f226617f0eb1e8f22 upstream.
    
    For some reason we ended up kfree between spinlock lock and unlock,
    which can sleep.
    
    move the kfree out of spinlock section.
    
    Fixes: a2a5d30218fd ("ASoC: qdsp6: q6asm: Add support to memory map and unmap")
    Cc: Stable@vger.kernel.org
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
    Link: https://patch.msgid.link/20251017085307.4325-2-srinivas.kandagatla@oss.qualcomm.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef226cacf564f06e52a3b2a04b4924de5e22bca6
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Oct 27 16:43:37 2025 +0800

    fbdev: valkyriefb: Fix reference count leak in valkyriefb_init
    
    commit eb53368f8d6e2dfba84c8a94d245719bcf9ae270 upstream.
    
    The of_find_node_by_name() function returns a device tree node with its
    reference count incremented. The caller is responsible for calling
    of_node_put() to release this reference when done.
    
    Found via static analysis.
    
    Fixes: cc5d0189b9ba ("[PATCH] powerpc: Remove device_node addrs/n_addr")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcc3a66044d6a1fb52cce76033665f32bb09a1d1
Author: Florian Fuchs <fuchsfl@gmail.com>
Date:   Sun Oct 26 00:38:50 2025 +0200

    fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS
    
    commit 5f566c0ac51cd2474e47da68dbe719d3acf7d999 upstream.
    
    Commit e24cca19babe ("sh: Kill off MAX_DMA_ADDRESS leftovers.") removed
    the define ONCHIP_NR_DMA_CHANNELS. So that the leftover reference needs
    to be replaced by CONFIG_NR_ONCHIP_DMA_CHANNELS to compile successfully
    with CONFIG_PVR2_DMA enabled.
    
    Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1fc9afcce9139791260f962541282d47fbb508d
Author: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
Date:   Mon Oct 13 15:58:19 2025 +0530

    wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode
    
    commit 3776c685ebe5f43e9060af06872661de55e80b9a upstream.
    
    Currently, whenever there is a need to transmit an Action frame,
    the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to
    firmware. The P2P interfaces were available when wpa_supplicant is managing
    the wlan interface.
    
    However, the P2P interfaces are not created/initialized when only hostapd
    is managing the wlan interface. And if hostapd receives an ANQP Query REQ
    Action frame even from an un-associated STA, the brcmfmac driver tries
    to use an uninitialized P2P vif pointer for sending the IOVAR to firmware.
    This NULL pointer dereferencing triggers a driver crash.
    
     [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual
     address 0000000000000000
     [...]
     [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
     [...]
     [ 1417.075653] Call trace:
     [ 1417.075662]  brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac]
     [ 1417.075738]  brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac]
     [ 1417.075810]  cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211]
     [ 1417.076067]  nl80211_tx_mgmt+0x238/0x388 [cfg80211]
     [ 1417.076281]  genl_family_rcv_msg_doit+0xe0/0x158
     [ 1417.076302]  genl_rcv_msg+0x220/0x2a0
     [ 1417.076317]  netlink_rcv_skb+0x68/0x140
     [ 1417.076330]  genl_rcv+0x40/0x60
     [ 1417.076343]  netlink_unicast+0x330/0x3b8
     [ 1417.076357]  netlink_sendmsg+0x19c/0x3f8
     [ 1417.076370]  __sock_sendmsg+0x64/0xc0
     [ 1417.076391]  ____sys_sendmsg+0x268/0x2a0
     [ 1417.076408]  ___sys_sendmsg+0xb8/0x118
     [ 1417.076427]  __sys_sendmsg+0x90/0xf8
     [ 1417.076445]  __arm64_sys_sendmsg+0x2c/0x40
     [ 1417.076465]  invoke_syscall+0x50/0x120
     [ 1417.076486]  el0_svc_common.constprop.0+0x48/0xf0
     [ 1417.076506]  do_el0_svc+0x24/0x38
     [ 1417.076525]  el0_svc+0x30/0x100
     [ 1417.076548]  el0t_64_sync_handler+0x100/0x130
     [ 1417.076569]  el0t_64_sync+0x190/0x198
     [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)
    
    Fix this, by always using the vif corresponding to the wdev on which the
    Action frame Transmission request was initiated by the userspace. This way,
    even if P2P vif is not available, the IOVAR is sent to firmware on AP vif
    and the ANQP Query RESP Action frame is transmitted without crashing the
    driver.
    
    Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()
    to brcmf_p2p_attach(). Because the former function would not get executed
    when only hostapd is managing wlan interface, and it is not safe to do
    reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior
    init_completion().
    
    And in the brcmf_p2p_tx_action_frame() function, the condition check for
    P2P Presence response frame is not needed, since the wpa_supplicant is
    properly sending the P2P Presense Response frame on the P2P-GO vif instead
    of the P2P-Device vif.
    
    Cc: stable@vger.kernel.org
    Fixes: 18e2f61db3b7 ("brcmfmac: P2P action frame tx")
    Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Link: https://patch.msgid.link/20251013102819.9727-1-gokulkumar.sivakumar@infineon.com
    [Cc stable]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0998a6cb232674408a03e8561dc15aa266b2f53b
Author: Junjie Cao <junjie.cao@intel.com>
Date:   Mon Oct 20 21:47:01 2025 +0800

    fbdev: bitblit: bound-check glyph index in bit_putcs*
    
    commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream.
    
    bit_putcs_aligned()/unaligned() derived the glyph pointer from the
    character value masked by 0xff/0x1ff, which may exceed the actual font's
    glyph count and read past the end of the built-in font array.
    Clamp the index to the actual glyph count before computing the address.
    
    This fixes a global out-of-bounds read reported by syzbot.
    
    Reported-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
    Tested-by: syzbot+793cf822d213be1a74f2@syzkaller.appspotmail.com
    Signed-off-by: Junjie Cao <junjie.cao@intel.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba1704316492a0496c69334338ea1fdbf4c2fd34
Author: Yuhao Jiang <danisjiang@gmail.com>
Date:   Wed Oct 22 15:07:04 2025 -0500

    ACPI: video: Fix use-after-free in acpi_video_switch_brightness()
    
    commit 8f067aa59430266386b83c18b983ca583faa6a11 upstream.
    
    The switch_brightness_work delayed work accesses device->brightness
    and device->backlight, freed by acpi_video_dev_unregister_backlight()
    during device removal.
    
    If the work executes after acpi_video_bus_unregister_backlight()
    frees these resources, it causes a use-after-free when
    acpi_video_switch_brightness() dereferences device->brightness or
    device->backlight.
    
    Fix this by calling cancel_delayed_work_sync() for each device's
    switch_brightness_work in acpi_video_bus_remove_notify_handler()
    after removing the notify handler that queues the work. This ensures
    the work completes before the memory is freed.
    
    Fixes: 8ab58e8e7e097 ("ACPI / video: Fix backlight taking 2 steps on a brightness up/down keypress")
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Yuhao Jiang <danisjiang@gmail.com>
    Reviewed-by: Hans de Goede <hansg@kernel.org>
    [ rjw: Changelog edit ]
    Link: https://patch.msgid.link/20251022200704.2655507-1-danisjiang@gmail.com
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 452ebff2128e23eaf9650a2ca8fcb6b959b13b9e
Author: Daniel Palmer <daniel@0x0f.com>
Date:   Fri Oct 24 18:37:15 2025 +0900

    fbdev: atyfb: Check if pll_ops->init_pll failed
    
    commit 7073c7fc8d8ba47194e5fc58fcafc0efe7586e9b upstream.
    
    Actually check the return value from pll_ops->init_pll()
    as it can return an error.
    
    If the card's BIOS didn't run because it's not the primary VGA card
    the fact that the xclk source is unsupported is printed as shown
    below but the driver continues on regardless and on my machine causes
    a hard lock up.
    
    [   61.470088] atyfb 0000:03:05.0: enabling device (0080 -> 0083)
    [   61.476191] atyfb: using auxiliary register aperture
    [   61.481239] atyfb: 3D RAGE XL (Mach64 GR, PCI-33) [0x4752 rev 0x27]
    [   61.487569] atyfb: 512K SGRAM (1:1), 14.31818 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 63 MHz XCLK
    [   61.496112] atyfb: Unsupported xclk source:  5.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Daniel Palmer <daniel@0x0f.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16544f8512a0a216927871e80dcafbfbd0ae37df
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Oct 27 00:43:16 2025 +0800

    net: usb: asix_devices: Check return value of usbnet_get_endpoints
    
    commit dc89548c6926d68dfdda11bebc1a5258bc41d887 upstream.
    
    The code did not check the return value of usbnet_get_endpoints.
    Add checks and return the error if it fails to transfer the error.
    
    Found via static anlaysis and this is similar to
    commit 07161b2416f7 ("sr9800: Add check for usbnet_get_endpoints").
    
    Fixes: 933a27d39e0e ("USB: asix - Add AX88178 support and many other changes")
    Fixes: 2e55cc7210fe ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://patch.msgid.link/20251026164318.57624-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 930cb4fe3ab4061be31f20ee30bb72a66f7bb6d1
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Sep 30 10:05:20 2025 -0400

    NFSD: Fix crash in nfsd4_read_release()
    
    commit abb1f08a2121dd270193746e43b2a9373db9ad84 upstream.
    
    When tracing is enabled, the trace_nfsd_read_done trace point
    crashes during the pynfs read.testNoFh test.
    
    Fixes: 15a8b55dbb1b ("nfsd: call op_release, even when op_func returns an error")
    Cc: stable@vger.kernel.org
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fab7929a7f8c5253aaa381de1708490e4353e5b8
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Sep 22 12:09:14 2025 +0100

    btrfs: use smp_mb__after_atomic() when forcing COW in create_pending_snapshot()
    
    [ Upstream commit 45c222468d33202c07c41c113301a4b9c8451b8f ]
    
    After setting the BTRFS_ROOT_FORCE_COW flag on the root we are doing a
    full write barrier, smp_wmb(), but we don't need to, all we need is a
    smp_mb__after_atomic().  The use of the smp_wmb() is from the old days
    when we didn't use a bit and used instead an int field in the root to
    signal if cow is forced. After the int field was changed to a bit in
    the root's state (flags field), we forgot to update the memory barrier
    in create_pending_snapshot() to smp_mb__after_atomic(), but we did the
    change in commit_fs_roots() after clearing BTRFS_ROOT_FORCE_COW. That
    happened in commit 27cdeb7096b8 ("Btrfs: use bitfield instead of integer
    data type for the some variants in btrfs_root"). On the reader side, in
    should_cow_block(), we also use the counterpart smp_mb__before_atomic()
    which generates further confusion.
    
    So change the smp_wmb() to smp_mb__after_atomic(). In fact we don't
    even need any barrier at all since create_pending_snapshot() is called
    in the critical section of a transaction commit and therefore no one
    can concurrently join/attach the transaction, or start a new one, until
    the transaction is unblocked. By the time someone starts a new transaction
    and enters should_cow_block(), a lot of implicit memory barriers already
    took place by having acquired several locks such as fs_info->trans_lock
    and extent buffer locks on the root node at least. Nevertlheless, for
    consistency use smp_mb__after_atomic() after setting the force cow bit
    in create_pending_snapshot().
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29368300ed69e859a11b4596a0928b7da73f582f
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Aug 27 12:10:28 2025 +0100

    btrfs: always drop log root tree reference in btrfs_replay_log()
    
    [ Upstream commit 2f5b8095ea47b142c56c09755a8b1e14145a2d30 ]
    
    Currently we have this odd behaviour:
    
    1) At btrfs_replay_log() we drop the reference of the log root tree if
       the call to btrfs_recover_log_trees() failed;
    
    2) But if the call to btrfs_recover_log_trees() did not fail, we don't
       drop the reference in btrfs_replay_log() - we expect that
       btrfs_recover_log_trees() does it in case it returns success.
    
    Let's simplify this and make btrfs_replay_log() always drop the reference
    on the log root tree, not only this simplifies code as it's what makes
    sense since it's btrfs_replay_log() who grabbed the reference in the first
    place.
    
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit def8568fe1df3a81b5aa6b9d2b76fa7f3ba8c89f
Author: David Kaplan <david.kaplan@amd.com>
Date:   Mon Sep 15 08:47:05 2025 -0500

    x86/bugs: Fix reporting of LFENCE retpoline
    
    [ Upstream commit d1cc1baef67ac6c09b74629ca053bf3fb812f7dc ]
    
    The LFENCE retpoline mitigation is not secure but the kernel prints
    inconsistent messages about this fact.  The dmesg log says 'Mitigation:
    LFENCE', implying the system is mitigated.  But sysfs reports 'Vulnerable:
    LFENCE' implying the system (correctly) is not mitigated.
    
    Fix this by printing a consistent 'Vulnerable: LFENCE' string everywhere
    when this mitigation is selected.
    
    Signed-off-by: David Kaplan <david.kaplan@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/20250915134706.3201818-1-david.kaplan@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99fc137f178797204d36ac860dd8b31e35baa2df
Author: Xiang Mei <xmei5@asu.edu>
Date:   Sat Jul 5 14:21:43 2025 -0700

    net/sched: sch_qfq: Fix null-deref in agg_dequeue
    
    commit dd831ac8221e691e9e918585b1003c7071df0379 upstream.
    
    To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)
    when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return
    value before using it, similar to the existing approach in sch_hfsc.c.
    
    To avoid code duplication, the following changes are made:
    
    1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static
    inline function.
    
    2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to
    include/net/pkt_sched.h so that sch_qfq can reuse it.
    
    3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.
    
    Signed-off-by: Xiang Mei <xmei5@asu.edu>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Link: https://patch.msgid.link/20250705212143.3982664-1-xmei5@asu.edu
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>