Changelog in Linux kernel 6.12.60

Author: Kuniyuki Iwashima <[email protected]>
Date:   Wed Jul 2 22:35:17 2025 +0000

    af_unix: Cache state->msg in unix_stream_read_generic().
    
    [ Upstream commit 8b77338eb2af74bb93986e4a8cfd86724168fe39 ]
    
    In unix_stream_read_generic(), state->msg is fetched multiple times.
    
    Let's cache it in a local variable.
    
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 7bf3a476ce43 ("af_unix: Read sk_peek_offset() again after sleeping in unix_stream_read_generic().")
    Signed-off-by: Sasha Levin <[email protected]>

Author: Kuniyuki Iwashima <[email protected]>
Date:   Mon Nov 17 17:47:10 2025 +0000

    af_unix: Read sk_peek_offset() again after sleeping in unix_stream_read_generic().
    
    [ Upstream commit 7bf3a476ce43833c49fceddbe94ff3472e04e9bc ]
    
    Miao Wang reported a bug of SO_PEEK_OFF on AF_UNIX SOCK_STREAM
    socket.
    
    The unexpected behaviour is triggered when the peek offset is
    larger than the recv queue and the thread is unblocked by new
    data.
    
    Let's assume a socket which has "aaaa" in the recv queue and
    the peek offset is 4.
    
    First, unix_stream_read_generic() reads the offset 4 and skips
    the skb(s) of "aaaa" with the code below:
    
            skip = max(sk_peek_offset(sk, flags), 0);       /* @skip is 4. */
    
            do {
            ...
                    while (skip >= unix_skb_len(skb)) {
                            skip -= unix_skb_len(skb);
                    ...
                            skb = skb_peek_next(skb, &sk->sk_receive_queue);
                            if (!skb)
                                    goto again;             /* @skip is 0. */
                    }
    
    The thread jumps to the 'again' label and goes to sleep since
    new data has not arrived yet.
    
    Later, new data "bbbb" unblocks the thread, and the thread jumps
    to the 'redo:' label to restart the entire process from the first
    skb in the recv queue.
    
            do {
                    ...
    redo:
                    ...
                    last = skb = skb_peek(&sk->sk_receive_queue);
                    ...
    again:
                    if (skb == NULL) {
                            ...
                            timeo = unix_stream_data_wait(sk, timeo, last,
                                                          last_len, freezable);
                            ...
                            goto redo;                      /* @skip is 0 !! */
    
    However, the peek offset is not reset in the path.
    
    If the buffer size is 8, recv() will return "aaaabbbb" without
    skipping any data, and the final offset will be 12 (the original
    offset 4 + peeked skbs' length 8).
    
    After sleeping in unix_stream_read_generic(), we have to fetch the
    peek offset again.
    
    Let's move the redo label before mutex_lock(&u->iolock).
    
    Fixes: 9f389e35674f ("af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag")
    Reported-by: Miao Wang <[email protected]>
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Takashi Iwai <[email protected]>
Date:   Wed Nov 26 11:08:31 2025 +0100

    ALSA: usb-audio: Fix missing unlock at error path of maxpacksize check
    
    The recent backport of the upstream commit 05a1fc5efdd8 ("ALSA:
    usb-audio: Fix potential overflow of PCM transfer buffer") on the
    older stable kernels like 6.12.y was broken since it doesn't consider
    the mutex unlock, where the upstream code manages with guard().
    In the older code, we still need an explicit unlock.
    
    This is a fix that corrects the error path, applied only on old stable
    trees.
    
    Reported-by: Pavel Machek <[email protected]>
    Closes: https://lore.kernel.org/[email protected]
    Fixes: 98e9d5e33bda ("ALSA: usb-audio: Fix potential overflow of PCM transfer buffer")
    Reviewed-by: Pavel Machek <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: René Rebe <[email protected]>
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 <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Quentin Schulz <[email protected]>
Date:   Wed Nov 12 16:01:53 2025 +0100

    arm64: dts: rockchip: disable HS400 on RK3588 Tiger
    
    commit baa18d577cd445145039e731d3de0fa49ca57204 upstream.
    
    We've had reports from the field that some RK3588 Tiger have random
    issues with eMMC errors.
    
    Applying commit a28352cf2d2f ("mmc: sdhci-of-dwcmshc: Change
    DLL_STRBIN_TAPNUM_DEFAULT to 0x4") didn't help and seemed to have made
    things worse for our board.
    
    Our HW department checked the eMMC lines and reported that they are too
    long and don't look great so signal integrity is probably not the best.
    
    Note that not all Tigers with the same eMMC chip have errors, so the
    suspicion is that we're really on the edge in terms of signal integrity
    and only a handful devices are failing. Additionally, we have RK3588
    Jaguars with the same eMMC chip but the layout is different and we also
    haven't received reports about those so far.
    
    Lowering the max-frequency to 150MHz from 200MHz instead of simply
    disabling HS400 was briefly tested and seem to work as well. We've
    disabled HS400 downstream and haven't received reports since so we'll go
    with that instead of lowering the max-frequency.
    
    Signed-off-by: Quentin Schulz <[email protected]>
    Fixes: 6173ef24b35b ("arm64: dts: rockchip: add RK3588-Q7 (Tiger) SoM")
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    [added Fixes tag and stable-cc from 2nd mail]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mykola Kvach <[email protected]>
Date:   Mon Nov 3 12:27:40 2025 +0200

    arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5
    
    commit b5414520793e68d266fdd97a84989d9831156aad upstream.
    
    The vcc3v3_pcie20 fixed regulator powers the PCIe device-side 3.3V rail
    for pcie2x1l2 via vpcie3v3-supply. The DTS mistakenly set its
    regulator-min/max-microvolt to 1800000 (1.8 V). Correct both to 3300000
    (3.3 V) to match the rail name, the PCIe/M.2 power requirement, and the
    actual hardware wiring on Orange Pi 5.
    
    Fixes: b6bc755d806e ("arm64: dts: rockchip: Add Orange Pi 5")
    Cc: [email protected]
    Signed-off-by: Mykola Kvach <[email protected]>
    Reviewed-by: Michael Riesch <[email protected]>
    Link: https://patch.msgid.link/cf6e08dfdfbf1c540685d12388baab1326f95d2c.1762165324.git.xakep.amatop@gmail.com
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Diederik de Haas <[email protected]>
Date:   Mon Oct 27 16:54:28 2025 +0100

    arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2
    
    commit 03c7e964a02e388ee168c804add7404eda23908c upstream.
    
    Page 13 of the PineTab2 v2 schematic dd 20230417 shows VCCIO4's power
    source is VCCIO_WL. Page 19 shows that VCCIO_WL is connected to
    VCCA1V8_PMU, so fix the PineTab2 dtsi to reflect that.
    
    Fixes: 1b7e19448f8f ("arm64: dts: rockchip: Add devicetree for Pine64 PineTab2")
    Cc: [email protected]
    Reviewed-by: Dragan Simic <[email protected]>
    Signed-off-by: Diederik de Haas <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Quentin Schulz <[email protected]>
Date:   Wed Oct 29 14:50:59 2025 +0100

    arm64: dts: rockchip: include rk3399-base instead of rk3399 in rk3399-op1
    
    commit 08d70143e3033d267507deb98a5fd187df3e6640 upstream.
    
    In commit 296602b8e5f7 ("arm64: dts: rockchip: Move RK3399 OPPs to dtsi
    files for SoC variants"), everything shared between variants of RK3399
    was put into rk3399-base.dtsi and the rest in variant-specific DTSI,
    such as rk3399-t, rk3399-op1, rk3399, etc.
    Therefore, the variant-specific DTSI should include rk3399-base.dtsi and
    not another variant's DTSI.
    
    rk3399-op1 wrongly includes rk3399 (a variant) DTSI instead of
    rk3399-base DTSI, let's fix this oversight by including the intended
    DTSI.
    
    Fortunately, this had no impact on the resulting DTB since all nodes
    were named the same and all node properties were overridden in
    rk3399-op1.dtsi. This was checked by doing a checksum of rk3399-op1 DTBs
    before and after this commit.
    
    No intended change in behavior.
    
    Fixes: 296602b8e5f7 ("arm64: dts: rockchip: Move RK3399 OPPs to dtsi files for SoC variants")
    Cc: [email protected]
    Signed-off-by: Quentin Schulz <[email protected]>
    Reviewed-by: Dragan Simic <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Yihang Li <[email protected]>
Date:   Thu Nov 20 11:50:23 2025 +0800

    ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()
    
    commit b32cc17d607e8ae7af037303fe101368cb4dc44c upstream.
    
    Call scsi_device_put() in ata_scsi_dev_rescan() if the device or its
    queue are not running.
    
    Fixes: 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume")
    Cc: [email protected]
    Signed-off-by: Yihang Li <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Niklas Cassel <[email protected]>
Date:   Wed Nov 19 15:13:14 2025 +0100

    ata: libata-scsi: Fix system suspend for a security locked drive
    
    commit b11890683380a36b8488229f818d5e76e8204587 upstream.
    
    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: [email protected]
    Reported-by: Ilia Baryshnikov <[email protected]>
    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 <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Rafał Miłecki <[email protected]>
Date:   Fri Oct 3 14:51:26 2025 +0200

    bcma: don't register devices disabled in OF
    
    [ Upstream commit a2a69add80411dd295c9088c1bcf925b1f4e53d7 ]
    
    Some bus devices can be marked as disabled for specific SoCs or models.
    Those should not be registered to avoid probing them.
    
    Signed-off-by: Rafał Miłecki <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Andrey Vatoropin <[email protected]>
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: [email protected]
    Signed-off-by: Andrey Vatoropin <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Carlos Llamas <[email protected]>
Date:   Thu Oct 30 04:39:18 2025 +0000

    blk-crypto: use BLK_STS_INVAL for alignment errors
    
    [ Upstream commit 0b39ca457241aeca07a613002512573e8804f93a ]
    
    Make __blk_crypto_bio_prep() propagate BLK_STS_INVAL when IO segments
    fail the data unit alignment check.
    
    This was flagged by an LTP test that expects EINVAL when performing an
    O_DIRECT read with a misaligned buffer [1].
    
    Cc: Eric Biggers <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/ [1]
    Signed-off-by: Carlos Llamas <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shaurya Rane <[email protected]>
Date:   Tue Nov 18 20:32:57 2025 +0530

    cifs: fix memory leak in smb3_fs_context_parse_param error path
    
    [ Upstream commit 7e4d9120cfa413dd34f4f434befc5dbe6c38b2e5 ]
    
    Add proper cleanup of ctx->source and fc->source to the
    cifs_parse_mount_err error handler. This ensures that memory allocated
    for the source strings is correctly freed on all error paths, matching
    the cleanup already performed in the success path by
    smb3_cleanup_fs_context_contents().
    Pointers are also set to NULL after freeing to prevent potential
    double-free issues.
    
    This change fixes a memory leak originally detected by syzbot. The
    leak occurred when processing Opt_source mount options if an error
    happened after ctx->source and fc->source were successfully
    allocated but before the function completed.
    
    The specific leak sequence was:
    1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory
    2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory
    3. A subsequent error jumps to cifs_parse_mount_err
    4. The old error handler freed passwords but not the source strings,
    causing the memory to leak.
    
    This issue was not addressed by commit e8c73eb7db0a ("cifs: client:
    fix memory leak in smb3_fs_context_parse_param"), which only fixed
    leaks from repeated fsconfig() calls but not this error path.
    
    Patch updated with minor change suggested by kernel test robot
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=87be6809ed9bf6d718e3
    Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api")
    Reviewed-by: David Howells <[email protected]>
    Signed-off-by: Shaurya Rane <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Steve French <[email protected]>
Date:   Fri Oct 24 21:17:01 2025 -0500

    cifs: fix typo in enable_gcm_256 module parameter
    
    [ Upstream commit f765fdfcd8b5bce92c6aa1a517ff549529ddf590 ]
    
    Fix typo in description of enable_gcm_256 module parameter
    
    Suggested-by: Thomas Spear <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shay Drory <[email protected]>
Date:   Mon Nov 17 14:05:49 2025 +0200

    devlink: rate: Unset parent pointer in devl_rate_nodes_destroy
    
    [ Upstream commit f94c1a114ac209977bdf5ca841b98424295ab1f0 ]
    
    The function devl_rate_nodes_destroy is documented to "Unset parent for
    all rate objects". However, it was only calling the driver-specific
    `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing
    the parent's refcount, without actually setting the
    `devlink_rate->parent` pointer to NULL.
    
    This leaves a dangling pointer in the `devlink_rate` struct, which cause
    refcount error in netdevsim[1] and mlx5[2]. In addition, this is
    inconsistent with the behavior of `devlink_nl_rate_parent_node_set`,
    where the parent pointer is correctly cleared.
    
    This patch fixes the issue by explicitly setting `devlink_rate->parent`
    to NULL after notifying the driver, thus fulfilling the function's
    documented behavior for all rate objects.
    
    [1]
    repro steps:
    echo 1 > /sys/bus/netdevsim/new_device
    devlink dev eswitch set netdevsim/netdevsim1 mode switchdev
    echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs
    devlink port function rate add netdevsim/netdevsim1/test_node
    devlink port function rate set netdevsim/netdevsim1/128 parent test_node
    echo 1 > /sys/bus/netdevsim/del_device
    
    dmesg:
    refcount_t: decrement hit 0; leaking memory.
    WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0
    CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:refcount_warn_saturate+0x42/0xe0
    Call Trace:
     <TASK>
     devl_rate_leaf_destroy+0x8d/0x90
     __nsim_dev_port_del+0x6c/0x70 [netdevsim]
     nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]
     nsim_drv_remove+0x2b/0xb0 [netdevsim]
     device_release_driver_internal+0x194/0x1f0
     bus_remove_device+0xc6/0x130
     device_del+0x159/0x3c0
     device_unregister+0x1a/0x60
     del_device_store+0x111/0x170 [netdevsim]
     kernfs_fop_write_iter+0x12e/0x1e0
     vfs_write+0x215/0x3d0
     ksys_write+0x5f/0xd0
     do_syscall_64+0x55/0x10f0
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    [2]
    devlink dev eswitch set pci/0000:08:00.0 mode switchdev
    devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000
    devlink port function rate add pci/0000:08:00.0/group1
    devlink port function rate set pci/0000:08:00.0/32768 parent group1
    modprobe -r mlx5_ib mlx5_fwctl mlx5_core
    
    dmesg:
    refcount_t: decrement hit 0; leaking memory.
    WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0
    CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
    RIP: 0010:refcount_warn_saturate+0x42/0xe0
    Call Trace:
     <TASK>
     devl_rate_leaf_destroy+0x8d/0x90
     mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]
     mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]
     mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]
     mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]
     notifier_call_chain+0x33/0xa0
     blocking_notifier_call_chain+0x3b/0x50
     mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]
     mlx5_eswitch_disable+0x63/0x90 [mlx5_core]
     mlx5_unload+0x1d/0x170 [mlx5_core]
     mlx5_uninit_one+0xa2/0x130 [mlx5_core]
     remove_one+0x78/0xd0 [mlx5_core]
     pci_device_remove+0x39/0xa0
     device_release_driver_internal+0x194/0x1f0
     unbind_store+0x99/0xa0
     kernfs_fop_write_iter+0x12e/0x1e0
     vfs_write+0x215/0x3d0
     ksys_write+0x5f/0xd0
     do_syscall_64+0x53/0x1f0
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    Fixes: d75559845078 ("devlink: Allow setting parent node of rate objects")
    Signed-off-by: Shay Drory <[email protected]>
    Reviewed-by: Carolina Jubran <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Charlene Liu <[email protected]>
Date:   Tue Nov 25 09:51:28 2025 -0500

    drm/amd/display: avoid reset DTBCLK at clock init
    
    [ Upstream commit 0ae47e971b9add8f7b8f8d55ac5f407f6f346758 ]
    
    [why & how]
    this is to init to HW real DTBCLK.
    and use real HW DTBCLK status to update internal logic state
    
    Reviewed-by: Nicholas Kazlauskas <[email protected]>
    Reviewed-by: Martin Leung <[email protected]>
    Signed-off-by: Charlene Liu <[email protected]>
    Signed-off-by: Ausef Yousof <[email protected]>
    Signed-off-by: Tom Chung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: cfa0904a35fd ("drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Ivan Lipski <[email protected]>
Date:   Wed Nov 5 15:27:42 2025 -0500

    drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5
    
    commit 5bab4c89390f32b2f491f49a151948cd226dd909 upstream.
    
    [Why]
    On DCN20 & DCN30, the 6th DPP's & HUBP's are powered on permanently and
    cannot be power gated. Thus, when dpp_reset() is invoked for the DPP5,
    while it's still powered on, the cached cursor_state
    (dpp_base->pos.cur0_ctl.bits.cur0_enable)
    and the actual state (CUR0_ENABLE) bit are unsycned. This can cause a
    double cursor in full screen with non-native scaling.
    
    [How]
    Force disable cursor on DPP5 on plane powerdown for ASICs w/ 6 DPPs/HUBPs.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4673
    Reviewed-by: Aric Cyr <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 79b3c037f972dcb13e325a8eabfb8da835764e15)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Charlene Liu <[email protected]>
Date:   Tue Nov 25 09:51:29 2025 -0500

    drm/amd/display: disable DPP RCG before DPP CLK enable
    
    [ Upstream commit 1bcd679209420305a86833bc357d50021909edaf ]
    
    [why]
    DPP CLK enable needs to disable DPPCLK RCG first.
    The DPPCLK_en in dccg should always be enabled when the corresponding
    pipe is enabled.
    
    Reviewed-by: Hansen Dsouza <[email protected]>
    Signed-off-by: Charlene Liu <[email protected]>
    Signed-off-by: Ray Wu <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: cfa0904a35fd ("drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Fangzhi Zuo <[email protected]>
Date:   Fri Nov 7 15:01:30 2025 -0500

    drm/amd/display: Fix pbn to kbps Conversion
    
    commit 1788ef30725da53face7e311cdf62ad65fababcd upstream.
    
    [Why]
    Existing routine has two conversion sequence,
    pbn_to_kbps and kbps_to_pbn with margin.
    Non of those has without-margin calculation.
    
    kbps_to_pbn with margin conversion includes
    fec overhead which has already been included in
    pbn_div calculation with 0.994 factor considered.
    It is a double counted fec overhead factor that causes
    potential bw loss.
    
    [How]
    Add without-margin calculation.
    Fix fec overhead double counted issue.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3735
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Fangzhi Zuo <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit e0dec00f3d05e8c0eceaaebfdca217f8d10d380c)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Mon Nov 3 12:11:31 2025 -0600

    drm/amd/display: Increase DPCD read retries
    
    commit 8612badc331bcab2068baefa69e1458085ed89e3 upstream.
    
    [Why]
    Empirical measurement of some monitors that fail to read EDID while
    booting shows that the number of retries with a 30ms delay between
    tries is as high as 16.
    
    [How]
    Increase number of retries to 20.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit ad1c59ad7cf74ec06e32fe2c330ac1e957222288)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Charlene Liu <[email protected]>
Date:   Tue Nov 25 09:51:30 2025 -0500

    drm/amd/display: Insert dccg log for easy debug
    
    [ Upstream commit 35bcc9168f3ce6416cbf3f776758be0937f84cb3 ]
    
    [why]
    Log for sequence tracking
    
    Reviewed-by: Ovidiu (Ovi) Bunea <[email protected]>
    Reviewed-by: Yihan Zhu <[email protected]>
    Signed-off-by: Charlene Liu <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Stable-dep-of: cfa0904a35fd ("drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Mon Nov 3 11:17:44 2025 -0600

    drm/amd/display: Move sleep into each retry for retrieve_link_cap()
    
    commit 71ad9054c1f241be63f9d11df8cbd0aa0352fe16 upstream.
    
    [Why]
    When a monitor is booting it's possible that it isn't ready to retrieve
    link caps and this can lead to an EDID read failure:
    
    ```
    [drm:retrieve_link_cap [amdgpu]] *ERROR* retrieve_link_cap: Read receiver caps dpcd data failed.
    amdgpu 0000:c5:00.0: [drm] *ERROR* No EDID read.
    ```
    
    [How]
    Rather than msleep once and try a few times, msleep each time.  Should
    be no changes for existing working monitors, but should correct reading
    caps on a monitor that is slow to boot.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Ivan Lipski <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 669dca37b3348a447db04bbdcbb3def94d5997cc)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Fangzhi Zuo <[email protected]>
Date:   Tue Nov 25 09:51:31 2025 -0500

    drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched
    
    [ Upstream commit cfa0904a35fd0231f4d05da0190f0a22ed881cce ]
    
    [why]
    1. With allow_0_dtb_clk enabled, the time required to latch DTBCLK to 600 MHz
    depends on the SMU. If DTBCLK is not latched to 600 MHz before set_mode completes,
    gating DTBCLK causes the DP2 sink to lose its clock source.
    
    2. The existing DTBCLK gating sequence ungates DTBCLK based on both pix_clk and ref_dtbclk,
    but gates DTBCLK when either pix_clk or ref_dtbclk is zero.
    pix_clk can be zero outside the set_mode sequence before DTBCLK is properly latched,
    which can lead to DTBCLK being gated by mistake.
    
    [how]
    Consider both pixel_clk and ref_dtbclk when determining when it is safe to gate DTBCLK;
    this is more accurate.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4701
    Fixes: 5949e7c4890c ("drm/amd/display: Enable Dynamic DTBCLK Switch")
    Reviewed-by: Charlene Liu <[email protected]>
    Reviewed-by: Aurabindo Pillai <[email protected]>
    Signed-off-by: Fangzhi Zuo <[email protected]>
    Signed-off-by: Roman Li <[email protected]>
    Tested-by: Dan Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit d04eb0c402780ca037b62a6aecf23b863545ebca)
    Cc: [email protected]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mario Limonciello <[email protected]>
Date:   Tue Nov 18 07:18:10 2025 -0600

    drm/amd: Skip power ungate during suspend for VPE
    
    commit 31ab31433c9bd2f255c48dc6cb9a99845c58b1e4 upstream.
    
    During the suspend sequence VPE is already going to be power gated
    as part of vpe_suspend().  It's unnecessary to call during calls to
    amdgpu_device_set_pg_state().
    
    It actually can expose a race condition with the firmware if s0i3
    sequence starts as well.  Drop these calls.
    
    Cc: [email protected]
    Reviewed-by: Alex Deucher <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 2a6c826cfeedd7714611ac115371a959ead55bda)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Samuel Zhang <[email protected]>
Date:   Wed Nov 5 03:04:08 2025 +0000

    drm/amdgpu: fix gpu page fault after hibernation on PF passthrough
    
    [ Upstream commit eb6e7f520d6efa4d4ebf1671455abe4a681f7a05 ]
    
    On PF passthrough environment, after hibernate and then resume, coralgemm
    will cause gpu page fault.
    
    Mode1 reset happens during hibernate, but partition mode is not restored
    on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right
    after resume. When CP access the MQD BO, wrong stride size is used,
    this will cause out of bound access on the MQD BO, resulting page fault.
    
    The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called
    when resume from a hibernation.
    KFD resume is called separately during a reset recovery or resume from
    suspend sequence. Hence it's not required to be called as part of
    partition switch.
    
    Signed-off-by: Samuel Zhang <[email protected]>
    Reviewed-by: Lijo Lazar <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yifan Zha <[email protected]>
Date:   Fri Nov 14 17:48:58 2025 +0800

    drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled
    
    commit 80d8a9ad1587b64c545d515ab6cb7ecb9908e1b3 upstream.
    
    [Why]
    Accoreding to CP updated to RS64 on gfx11,
    WRITE_DATA with PREEMPTION_META_MEMORY(dst_sel=8) is illegal for CP FW.
    That packet is used for MCBP on F32 based system.
    So it would lead to incorrect GRBM write and FW is not handling that
    extra case correctly.
    
    [How]
    With gfx11 rs64 enabled, skip emit de meta data.
    
    Signed-off-by: Yifan Zha <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 8366cd442d226463e673bed5d199df916f4ecbcf)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Imre Deak <[email protected]>
Date:   Fri Nov 21 11:05:47 2025 -0500

    drm/i915/dp_mst: Disable Panel Replay
    
    [ Upstream commit f2687d3cc9f905505d7b510c50970176115066a2 ]
    
    Disable Panel Replay on MST links until it's properly implemented. For
    instance the required VSC SDP is not programmed on MST and FEC is not
    enabled if Panel Replay is enabled.
    
    Fixes: 3257e55d3ea7 ("drm/i915/panelreplay: enable/disable panel replay")
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15174
    Cc: Jouni Högander <[email protected]>
    Cc: Animesh Manna <[email protected]>
    Cc: [email protected] # v6.8+
    Reviewed-by: Jouni Högander <[email protected]>
    Signed-off-by: Imre Deak <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    (cherry picked from commit e109f644b871df8440c886a69cdce971ed533088)
    Signed-off-by: Rodrigo Vivi <[email protected]>
    [ placed MST check at function start since DPCD read was moved to caller ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Robert McClinton <[email protected]>
Date:   Sun Nov 16 12:33:21 2025 -0500

    drm/radeon: delete radeon_fence_process in is_signaled, no deadlock
    
    commit 9eb00b5f5697bd56baa3222c7a1426fa15bacfb5 upstream.
    
    Delete the attempt to progress the queue when checking if fence is
    signaled. This avoids deadlock.
    
    dma-fence_ops::signaled can be called with the fence lock in unknown
    state. For radeon, the fence lock is also the wait queue lock. This can
    cause a self deadlock when signaled() tries to make forward progress on
    the wait queue. But advancing the queue is unneeded because incorrectly
    returning false from signaled() is perfectly acceptable.
    
    Link: https://github.com/brave/brave-browser/issues/49182
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4641
    Cc: Alex Deucher <[email protected]>
    Signed-off-by: Robert McClinton <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Prateek Agarwal <[email protected]>
Date:   Fri Sep 19 13:25:40 2025 +0900

    drm/tegra: Add call to put_pid()
    
    [ Upstream commit 6cbab9f0da72b4dc3c3f9161197aa3b9daa1fa3a ]
    
    Add a call to put_pid() corresponding to get_task_pid().
    host1x_memory_context_alloc() does not take ownership of the PID so we
    need to free it here to avoid leaking.
    
    Signed-off-by: Prateek Agarwal <[email protected]>
    Fixes: e09db97889ec ("drm/tegra: Support context isolation")
    [[email protected]: reword commit message]
    Signed-off-by: Mikko Perttunen <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ma Ke <[email protected]>
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: [email protected]
    Fixes: a31500fe7055 ("drm/tegra: dc: Restore coupling of display controllers")
    Signed-off-by: Ma Ke <[email protected]>
    Acked-by: Mikko Perttunen <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Shuicheng Lin <[email protected]>
Date:   Mon Nov 24 22:28:28 2025 +0000

    drm/xe: Prevent BIT() overflow when handling invalid prefetch region
    
    [ Upstream commit d52dea485cd3c98cfeeb474cf66cf95df2ab142f ]
    
    If user provides a large value (such as 0x80) for parameter
    prefetch_mem_region_instance in vm_bind ioctl, it will cause
    BIT(prefetch_region) overflow as below:
    "
     ------------[ cut here ]------------
     UBSAN: shift-out-of-bounds in drivers/gpu/drm/xe/xe_vm.c:3414:7
     shift exponent 128 is too large for 64-bit type 'long unsigned int'
     CPU: 8 UID: 0 PID: 53120 Comm: xe_exec_system_ Tainted: G        W           6.18.0-rc1-lgci-xe-kernel+ #200 PREEMPT(voluntary)
     Tainted: [W]=WARN
     Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023
     Call Trace:
      <TASK>
      dump_stack_lvl+0xa0/0xc0
      dump_stack+0x10/0x20
      ubsan_epilogue+0x9/0x40
      __ubsan_handle_shift_out_of_bounds+0x10e/0x170
      ? mutex_unlock+0x12/0x20
      xe_vm_bind_ioctl.cold+0x20/0x3c [xe]
     ...
    "
    Fix it by validating prefetch_region before the BIT() usage.
    
    v2: Add Closes and Cc stable kernels. (Matt)
    
    Reported-by: Koen Koning <[email protected]>
    Reported-by: Peter Senna Tschudin <[email protected]>
    Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
    Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6478
    Cc: <[email protected]> # v6.8+
    Reviewed-by: Matthew Auld <[email protected]>
    Signed-off-by: Shuicheng Lin <[email protected]>
    Signed-off-by: Matthew Auld <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    (cherry picked from commit 8f565bdd14eec5611cc041dba4650e42ccdf71d9)
    Signed-off-by: Lucas De Marchi <[email protected]>
    (cherry picked from commit d52dea485cd3c98cfeeb474cf66cf95df2ab142f)
    Signed-off-by: Shuicheng Lin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Oct 22 15:34:26 2025 +0200

    dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups
    
    commit 316e361b5d2cdeb8d778983794a1c6eadcb26814 upstream.
    
    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: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Yongpeng Yang <[email protected]>
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: [email protected] # v6.15
    Fixes: 719c1e1829166d ("exfat: add super block operations")
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Yongpeng Yang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Mario Limonciello (AMD) <[email protected]>
Date:   Mon Oct 20 10:50:42 2025 -0500

    HID: amd_sfh: Stop sensor before starting
    
    commit 4d3a13afa8b64dc49293b3eab3e7beac11072c12 upstream.
    
    Titas reports that the accelerometer sensor on their laptop only
    works after a warm boot or unloading/reloading the amd-sfh kernel
    module.
    
    Presumably the sensor is in a bad state on cold boot and failing to
    start, so explicitly stop it before starting.
    
    Cc: [email protected]
    Fixes: 93ce5e0231d79 ("HID: amd_sfh: Implement SFH1.1 functionality")
    Reported-by: Titas <[email protected]>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220670
    Tested-by: Titas <[email protected]>
    Signed-off-by: Mario Limonciello (AMD) <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Zhang Heng <[email protected]>
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.
    
    [[email protected]: edit shortlog]
    Fixes: 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY")
    Cc: [email protected]
    Tested-by: [email protected]
    Reviewed-by: Terry Junge <[email protected]>
    Signed-off-by: Zhang Heng <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Grzegorz Nitka <[email protected]>
Date:   Mon Oct 20 12:02:16 2025 +0200

    ice: fix PTP cleanup on driver removal in error path
    
    [ Upstream commit 23a5b9b12de9dcd15ebae4f1abc8814ec1c51ab0 ]
    
    Improve the cleanup on releasing PTP resources in error path.
    The error case might happen either at the driver probe and PTP
    feature initialization or on PTP restart (errors in reset handling, NVM
    update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf
    function) and 'ps_lock' mutex deinitialization were missed.
    Additionally, ptp clock was not unregistered in the latter case.
    
    Keep PTP state as 'uninitialized' on init to distinguish between error
    scenarios and to avoid resource release duplication at driver removal.
    
    The consequence of missing ice_ptp_cleanup_pf call is the following call
    trace dumped when ice_adapter object is freed (port list is not empty,
    as it is required at this stage):
    
    [  T93022] ------------[ cut here ]------------
    [  T93022] WARNING: CPU: 10 PID: 93022 at
    ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice]
    ...
    [  T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice]
    ...
    [  T93022] Call Trace:
    [  T93022]  <TASK>
    [  T93022]  ? ice_adapter_put+0xef/0x100 [ice
    33d2647ad4f6d866d41eefff1806df37c68aef0c]
    [  T93022]  ? __warn.cold+0xb0/0x10e
    [  T93022]  ? ice_adapter_put+0xef/0x100 [ice
    33d2647ad4f6d866d41eefff1806df37c68aef0c]
    [  T93022]  ? report_bug+0xd8/0x150
    [  T93022]  ? handle_bug+0xe9/0x110
    [  T93022]  ? exc_invalid_op+0x17/0x70
    [  T93022]  ? asm_exc_invalid_op+0x1a/0x20
    [  T93022]  ? ice_adapter_put+0xef/0x100 [ice
    33d2647ad4f6d866d41eefff1806df37c68aef0c]
    [  T93022]  pci_device_remove+0x42/0xb0
    [  T93022]  device_release_driver_internal+0x19f/0x200
    [  T93022]  driver_detach+0x48/0x90
    [  T93022]  bus_remove_driver+0x70/0xf0
    [  T93022]  pci_unregister_driver+0x42/0xb0
    [  T93022]  ice_module_exit+0x10/0xdb0 [ice
    33d2647ad4f6d866d41eefff1806df37c68aef0c]
    ...
    [  T93022] ---[ end trace 0000000000000000 ]---
    [  T93022] ice: module unloaded
    
    Fixes: e800654e85b5 ("ice: Use ice_adapter for PTP shared data instead of auxdev")
    Signed-off-by: Grzegorz Nitka <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Emil Tantilov <[email protected]>
Date:   Mon Oct 13 08:08:24 2025 -0700

    idpf: fix possible vport_config NULL pointer deref in remove
    
    [ Upstream commit 118082368c2b6ddefe6cb607efc312285148f044 ]
    
    Attempting to remove the driver will cause a crash in cases where
    the vport failed to initialize. Following trace is from an instance where
    the driver failed during an attempt to create a VF:
    [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated
    [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms)
    [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028
    ...
    [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf]
    ...
    [ 1723.364973] Call Trace:
    [ 1723.365475]  <TASK>
    [ 1723.365972]  pci_device_remove+0x42/0xb0
    [ 1723.366481]  device_release_driver_internal+0x1a9/0x210
    [ 1723.366987]  pci_stop_bus_device+0x6d/0x90
    [ 1723.367488]  pci_stop_and_remove_bus_device+0x12/0x20
    [ 1723.367971]  pci_iov_remove_virtfn+0xbd/0x120
    [ 1723.368309]  sriov_disable+0x34/0xe0
    [ 1723.368643]  idpf_sriov_configure+0x58/0x140 [idpf]
    [ 1723.368982]  sriov_numvfs_store+0xda/0x1c0
    
    Avoid the NULL pointer dereference by adding NULL pointer check for
    vport_config[i], before freeing user_config.q_coalesce.
    
    Fixes: e1e3fec3e34b ("idpf: preserve coalescing settings across resets")
    Signed-off-by: Emil Tantilov <[email protected]>
    Reviewed-by: Chittim Madhu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Samuel Salin <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Tzung-Bi Shih <[email protected]>
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 <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Hans de Goede <[email protected]>
Date:   Mon Oct 13 09:15:25 2025 -0700

    Input: goodix - add support for ACPI ID GDIX1003
    
    commit c6d99e488117201c63efd747ce17b80687c3f5a9 upstream.
    
    Some newer devices use an ACPI hardware ID of GDIX1003 for their Goodix
    touchscreen controller, instead of GDIX1001 / GDIX1002. Add GDIX1003
    to the goodix_acpi_match[] table.
    
    Reported-by: Weikang Guo <[email protected]>
    Closes: https://lore.kernel.org/linux-input/[email protected]/
    Tested-by: Weikang Guo <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Dan Carpenter <[email protected]>
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 <[email protected]>
    Reviewed-by: Peng Fan <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Seungjin Bae <[email protected]>
Date:   Fri Oct 17 15:36:31 2025 -0700

    Input: pegasus-notetaker - fix potential out-of-bounds access
    
    commit 69aeb507312306f73495598a055293fa749d454e upstream.
    
    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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Cc: [email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Yongpeng Yang <[email protected]>
Date:   Tue Nov 4 20:50:08 2025 +0800

    isofs: check the return value of sb_min_blocksize() in isofs_fill_super
    
    commit e106e269c5cb38315eb0a0e7e38f71e9b20c8c66 upstream.
    
    sb_min_blocksize() may return 0. Check its return value to avoid
    opt->blocksize and sb->s_blocksize is 0.
    
    Cc: [email protected] # v6.15
    Fixes: 1b17a46c9243e9 ("isofs: convert isofs to use the new mount API")
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Yongpeng Yang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Jakub Horký <[email protected]>
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ý <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [nathan: Alphabetize locale.h include]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jakub Horký <[email protected]>
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ý <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [nathan: Alphabetize locale.h include]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sebastian Ene <[email protected]>
Date:   Fri Oct 17 07:57:10 2025 +0000

    KVM: arm64: Check the untrusted offset in FF-A memory share
    
    commit 103e17aac09cdd358133f9e00998b75d6c1f1518 upstream.
    
    Verify the offset to prevent OOB access in the hypervisor
    FF-A buffer in case an untrusted large enough value
    [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX]
    is set from the host kernel.
    
    Signed-off-by: Sebastian Ene <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Marc Zyngier <[email protected]>
Date:   Sun Nov 23 10:39:09 2025 +0000

    KVM: arm64: Make all 32bit ID registers fully writable
    
    commit 3f9eacf4f0705876a5d6526d7d320ca91d7d7a16 upstream.
    
    32bit ID registers aren't getting much love these days, and are
    often missed in updates. One of these updates broke restoring
    a GICv2 guest on a GICv3 machine.
    
    Instead of performing a piecemeal fix, just bite the bullet
    and make all 32bit ID regs fully writable. KVM itself never
    relies on them for anything, and if the VMM wants to mess up
    the guest, so be it.
    
    Fixes: 5cb57a1aff755 ("KVM: arm64: Zero ID_AA64PFR0_EL1.GIC when no GICv3 is presented to the guest")
    Reported-by: Peter Maydell <[email protected]>
    Cc: [email protected]
    Reviewed-by: Oliver Upton <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Greg Kroah-Hartman <[email protected]>
Date:   Mon Dec 1 11:43:41 2025 +0100

    Linux 6.12.60
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Brett A C Sheffield <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Dileep Malepu <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Salvatore Bonaccorso <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Huacai Chen <[email protected]>
Date:   Thu Nov 20 14:42:05 2025 +0800

    LoongArch: Don't panic if no valid cache info for PCI
    
    commit a6b533adfc05ba15360631e019d3e18275080275 upstream.
    
    If there is no valid cache info detected (may happen in virtual machine)
    for pci_dfl_cache_line_size, kernel shouldn't panic. Because in the PCI
    core it will be evaluated to (L1_CACHE_BYTES >> 2).
    
    Cc: <[email protected]>
    Signed-off-by: Jiaxun Yang <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Thomas Weißschuh <[email protected]>
Date:   Thu Nov 20 14:42:05 2025 +0800

    LoongArch: Use UAPI types in ptrace UAPI header
    
    [ Upstream commit 20d7338f2d3bcb570068dd6d39b16f1a909fe976 ]
    
    The kernel UAPI headers already contain fixed-width integer types, there
    is no need to rely on the libc types. There may not be a libc available
    or the libc may not provides the <stdint.h>, like for example on nolibc.
    
    This also aligns the header with the rest of the LoongArch UAPI headers.
    
    Fixes: 803b0fc5c3f2 ("LoongArch: Add process management")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Signed-off-by: Huacai Chen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Martin Kaiser <[email protected]>
Date:   Thu Oct 30 16:55:05 2025 +0100

    maple_tree: fix tracepoint string pointers
    
    commit 91a54090026f84ceffaa12ac53c99b9f162946f6 upstream.
    
    maple_tree tracepoints contain pointers to function names. Such a pointer
    is saved when a tracepoint logs an event. There's no guarantee that it's
    still valid when the event is parsed later and the pointer is dereferenced.
    
    The kernel warns about these unsafe pointers.
    
            event 'ma_read' has unsafe pointer field 'fn'
            WARNING: kernel/trace/trace.c:3779 at ignore_event+0x1da/0x1e4
    
    Mark the function names as tracepoint_string() to fix the events.
    
    One case that doesn't work without my patch would be trace-cmd record
    to save the binary ringbuffer and trace-cmd report to parse it in
    userspace.  The address of __func__ can't be dereferenced from
    userspace but tracepoint_string will add an entry to
    /sys/kernel/tracing/printk_formats
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 54a611b60590 ("Maple Tree: add new data structure")
    Signed-off-by: Martin Kaiser <[email protected]>
    Acked-by: Liam R. Howlett <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Maciej W. Rozycki <[email protected]>
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 <[email protected]>
    Fixes: 422dd256642b ("MIPS: Malta: Allow PCI devices DMA to lower 2GB physical")
    Cc: [email protected] # v4.9+
    Signed-off-by: Thomas Bogendoerfer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Zilin Guan <[email protected]>
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 <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Vlastimil Babka <[email protected]>
Date:   Thu Nov 13 19:54:35 2025 +0100

    mm/mempool: fix poisoning order>0 pages with HIGHMEM
    
    commit ec33b59542d96830e3c89845ff833cf7b25ef172 upstream.
    
    The kernel test has reported:
    
      BUG: unable to handle page fault for address: fffba000
      #PF: supervisor write access in kernel mode
      #PF: error_code(0x0002) - not-present page
      *pde = 03171067 *pte = 00000000
      Oops: Oops: 0002 [#1]
      CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE  a1d066dfe789f54bc7645c7989957d2bdee593ca
      Tainted: [T]=RANDSTRUCT
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
      EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)
      Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56
      EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b
      ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8
      DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287
      CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690
      Call Trace:
       poison_element (mm/mempool.c:83 mm/mempool.c:102)
       mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)
       mempool_init_noprof (mm/mempool.c:250 (discriminator 1))
       ? mempool_alloc_pages (mm/mempool.c:640)
       bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))
       ? mempool_alloc_pages (mm/mempool.c:640)
       do_one_initcall (init/main.c:1283)
    
    Christoph found out this is due to the poisoning code not dealing
    properly with CONFIG_HIGHMEM because only the first page is mapped but
    then the whole potentially high-order page is accessed.
    
    We could give up on HIGHMEM here, but it's straightforward to fix this
    with a loop that's mapping, poisoning or checking and unmapping
    individual pages.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Analyzed-by: Christoph Hellwig <[email protected]>
    Fixes: bdfedb76f4f5 ("mm, mempool: poison elements backed by slab allocator")
    Cc: [email protected]
    Tested-by: kernel test robot <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Vlastimil Babka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Nov 18 08:20:20 2025 +0100

    mptcp: avoid unneeded subflow-level drops
    
    commit 4f102d747cadd8f595f2b25882eed9bec1675fb1 upstream.
    
    The rcv window is shared among all the subflows. Currently, MPTCP sync
    the TCP-level rcv window with the MPTCP one at tcp_transmit_skb() time.
    
    The above means that incoming data may sporadically observe outdated
    TCP-level rcv window and being wrongly dropped by TCP.
    
    Address the issue checking for the edge condition before queuing the
    data at TCP level, and eventually syncing the rcv window as needed.
    
    Note that the issue is actually present from the very first MPTCP
    implementation, but backports older than the blamed commit below will
    range from impossible to useless.
    
    Before:
    
      $ nstat -n; sleep 1; nstat -z TcpExtBeyondWindow
      TcpExtBeyondWindow              14                 0.0
    
    After:
    
      $ nstat -n; sleep 1; nstat -z TcpExtBeyondWindow
      TcpExtBeyondWindow              0                  0.0
    
    Fixes: fa3fe2b15031 ("mptcp: track window announced to peer")
    Cc: [email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-2-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Nov 18 08:20:23 2025 +0100

    mptcp: decouple mptcp fastclose from tcp close
    
    commit fff0c87996672816a84c3386797a5e69751c5888 upstream.
    
    With the current fastclose implementation, the mptcp_do_fastclose()
    helper is in charge of two distinct actions: send the fastclose reset
    and cleanup the subflows.
    
    Formally decouple the two steps, ensuring that mptcp explicitly closes
    all the subflows after the mentioned helper.
    
    This will make the upcoming fix simpler, and allows dropping the 2nd
    argument from mptcp_destroy_common(). The Fixes tag is then the same as
    in the next commit to help with the backports.
    
    Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios")
    Cc: [email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Geliang Tang <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-5-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Jiayuan Chen <[email protected]>
Date:   Tue Nov 11 14:02:50 2025 +0800

    mptcp: Disallow MPTCP subflows from sockmap
    
    commit fbade4bd08ba52cbc74a71c4e86e736f059f99f7 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()
      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
    '''
    Consider two scenarios:
    
    1. When the server has MPTCP enabled and the client also requests MPTCP,
       the sk passed to the BPF program is a subflow sk. Since subflows only
       handle partial data, replacing their sk_prot is meaningless and will
       cause traffic disruption.
    
    2. 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_ulp_fallback()
        subflow_drop_ctx()
          mptcp_subflow_ops_undo_override()
       '''
       Subsequently, accept::mptcp_stream_accept::mptcp_fallback_tcp_ops()
       converts the subflow to plain TCP.
    
    For the first case, we should prevent it from being combined with sockmap
    by setting sk_prot->psock_update_sk_prot to NULL, which will be blocked by
    sockmap's own flow.
    
    For the second case, since subflow_syn_recv_sock() has already restored
    sk_prot to native tcp_prot/tcpv6_prot, no further action is needed.
    
    Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections")
    Signed-off-by: Jiayuan Chen <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Nov 18 08:20:22 2025 +0100

    mptcp: do not fallback when OoO is present
    
    commit 1bba3f219c5e8c29e63afa3c1fc24f875ebec119 upstream.
    
    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: [email protected]
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/598
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-4-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Mon Nov 24 17:38:44 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: [email protected]
    Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/[email protected]
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Geliang Tang <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Nov 18 08:20:19 2025 +0100

    mptcp: fix ack generation for fallback msk
    
    commit 5e15395f6d9ec07395866c5511f4b4ac566c0c9b upstream.
    
    mptcp_cleanup_rbuf() needs to know the last most recent, mptcp-level
    rcv_wnd sent, and such information is tracked into the msk->old_wspace
    field, updated at ack transmission time by mptcp_write_options().
    
    Fallback socket do not add any mptcp options, such helper is never
    invoked, and msk->old_wspace value remain stale. That in turn makes
    ack generation at recvmsg() time quite random.
    
    Address the issue ensuring mptcp_write_options() is invoked even for
    fallback sockets, and just update the needed info in such a case.
    
    The issue went unnoticed for a long time, as mptcp currently overshots
    the fallback socket receive buffer autotune significantly. It is going
    to change in the near future.
    
    Fixes: e3859603ba13 ("mptcp: better msk receive window updates")
    Cc: [email protected]
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/594
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Geliang Tang <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-1-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Nov 18 08:20:24 2025 +0100

    mptcp: fix duplicate reset on fastclose
    
    commit ae155060247be8dcae3802a95bd1bdf93ab3215d upstream.
    
    The CI reports sporadic failures of the fastclose self-tests. The root
    cause is a duplicate reset, not carrying the relevant MPTCP option.
    In the failing scenario the bad reset is received by the peer before
    the fastclose one, preventing the reception of the latter.
    
    Indeed there is window of opportunity at fastclose time for the
    following race:
    
      mptcp_do_fastclose
        __mptcp_close_ssk
          __tcp_close()
            tcp_set_state() [1]
            tcp_send_active_reset() [2]
    
    After [1] the stack will send reset to in-flight data reaching the now
    closed port. Such reset may race with [2].
    
    Address the issue explicitly sending a single reset on fastclose before
    explicitly moving the subflow to close status.
    
    Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios")
    Cc: [email protected]
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/596
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Geliang Tang <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-6-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Paolo Abeni <[email protected]>
Date:   Tue Nov 18 08:20:21 2025 +0100

    mptcp: fix premature close in case of fallback
    
    commit 17393fa7b7086664be519e7230cb6ed7ec7d9462 upstream.
    
    I'm observing very frequent self-tests failures in case of fallback when
    running on a CONFIG_PREEMPT kernel.
    
    The root cause is that subflow_sched_work_if_closed() closes any subflow
    as soon as it is half-closed and has no incoming data pending.
    
    That works well for regular subflows - MPTCP needs bi-directional
    connectivity to operate on a given subflow - but for fallback socket is
    race prone.
    
    When TCP peer closes the connection before the MPTCP one,
    subflow_sched_work_if_closed() will schedule the MPTCP worker to
    gracefully close the subflow, and shortly after will do another schedule
    to inject and process a dummy incoming DATA_FIN.
    
    On CONFIG_PREEMPT kernel, the MPTCP worker can kick-in and close the
    fallback subflow before subflow_sched_work_if_closed() is able to create
    the dummy DATA_FIN, unexpectedly interrupting the transfer.
    
    Address the issue explicitly avoiding closing fallback subflows on when
    the peer is only half-closed.
    
    Note that, when the subflow is able to create the DATA_FIN before the
    worker invocation, the worker will change the msk state before trying to
    close the subflow and will skip the latter operation as the msk will not
    match anymore the precondition in __mptcp_close_subflow().
    
    Fixes: f09b0ad55a11 ("mptcp: close subflow when receiving TCP+FIN")
    Cc: [email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-3-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Jiayuan Chen <[email protected]>
Date:   Tue Nov 11 14:02:51 2025 +0800

    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 <[email protected]>
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Reviewed-by: Jakub Sitnicki <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Eric Dumazet <[email protected]>
Date:   Thu Nov 13 10:39:24 2025 +0000

    mptcp: fix race condition in mptcp_schedule_work()
    
    commit 035bca3f017ee9dea3a5a756e77a6f7138cc6eea upstream.
    
    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: [email protected]
    Fixes: 3b1d6210a957 ("mptcp: implement and use MPTCP-level retransmission")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Niravkumar L Rabara <[email protected]>
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: [email protected]
    Signed-off-by: Niravkumar L Rabara <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Dan Carpenter <[email protected]>
Date:   Tue Sep 30 15:32:34 2025 +0300

    mtdchar: fix integer overflow in read/write ioctls
    
    commit e4185bed738da755b191aa3f2e16e8b48450e1b8 upstream.
    
    The "req.start" and "req.len" variables are u64 values that come from the
    user at the start of the function.  We mask away the high 32 bits of
    "req.len" so that's capped at U32_MAX but the "req.start" variable can go
    up to U64_MAX which means that the addition can still integer overflow.
    
    Use check_add_overflow() to fix this bug.
    
    Fixes: 095bb6e44eb1 ("mtdchar: add MEMREAD ioctl")
    Fixes: 6420ac0af95d ("mtdchar: prevent unbounded allocation in MEMWRITE ioctl")
    Cc: [email protected]
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Pradyumn Rahar <[email protected]>
Date:   Mon Nov 17 14:16:08 2025 +0200

    net/mlx5: Clean up only new IRQ glue on request_irq() failure
    
    [ Upstream commit d47515af6cccd7484d8b0870376858c9848a18ec ]
    
    The mlx5_irq_alloc() function can inadvertently free the entire rmap
    and end up in a crash[1] when the other threads tries to access this,
    when request_irq() fails due to exhausted IRQ vectors. This commit
    modifies the cleanup to remove only the specific IRQ mapping that was
    just added.
    
    This prevents removal of other valid mappings and ensures precise
    cleanup of the failed IRQ allocation's associated glue object.
    
    Note: This error is observed when both fwctl and rds configs are enabled.
    
    [1]
    mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1
    mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to
    request irq. err = -28
    infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while
    trying to test write-combining support
    mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1
    mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1
    mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to
    request irq. err = -28
    infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while
    trying to test write-combining support
    mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1
    mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to
    request irq. err = -28
    mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to
    request irq. err = -28
    general protection fault, probably for non-canonical address
    0xe277a58fde16f291: 0000 [#1] SMP NOPTI
    
    RIP: 0010:free_irq_cpu_rmap+0x23/0x7d
    Call Trace:
       <TASK>
       ? show_trace_log_lvl+0x1d6/0x2f9
       ? show_trace_log_lvl+0x1d6/0x2f9
       ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]
       ? __die_body.cold+0x8/0xa
       ? die_addr+0x39/0x53
       ? exc_general_protection+0x1c4/0x3e9
       ? dev_vprintk_emit+0x5f/0x90
       ? asm_exc_general_protection+0x22/0x27
       ? free_irq_cpu_rmap+0x23/0x7d
       mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]
       irq_pool_request_vector+0x7d/0x90 [mlx5_core]
       mlx5_irq_request+0x2e/0xe0 [mlx5_core]
       mlx5_irq_request_vector+0xad/0xf7 [mlx5_core]
       comp_irq_request_pci+0x64/0xf0 [mlx5_core]
       create_comp_eq+0x71/0x385 [mlx5_core]
       ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core]
       mlx5_comp_eqn_get+0x72/0x90 [mlx5_core]
       ? xas_load+0x8/0x91
       mlx5_comp_irqn_get+0x40/0x90 [mlx5_core]
       mlx5e_open_channel+0x7d/0x3c7 [mlx5_core]
       mlx5e_open_channels+0xad/0x250 [mlx5_core]
       mlx5e_open_locked+0x3e/0x110 [mlx5_core]
       mlx5e_open+0x23/0x70 [mlx5_core]
       __dev_open+0xf1/0x1a5
       __dev_change_flags+0x1e1/0x249
       dev_change_flags+0x21/0x5c
       do_setlink+0x28b/0xcc4
       ? __nla_parse+0x22/0x3d
       ? inet6_validate_link_af+0x6b/0x108
       ? cpumask_next+0x1f/0x35
       ? __snmp6_fill_stats64.constprop.0+0x66/0x107
       ? __nla_validate_parse+0x48/0x1e6
       __rtnl_newlink+0x5ff/0xa57
       ? kmem_cache_alloc_trace+0x164/0x2ce
       rtnl_newlink+0x44/0x6e
       rtnetlink_rcv_msg+0x2bb/0x362
       ? __netlink_sendskb+0x4c/0x6c
       ? netlink_unicast+0x28f/0x2ce
       ? rtnl_calcit.isra.0+0x150/0x146
       netlink_rcv_skb+0x5f/0x112
       netlink_unicast+0x213/0x2ce
       netlink_sendmsg+0x24f/0x4d9
       __sock_sendmsg+0x65/0x6a
       ____sys_sendmsg+0x28f/0x2c9
       ? import_iovec+0x17/0x2b
       ___sys_sendmsg+0x97/0xe0
       __sys_sendmsg+0x81/0xd8
       do_syscall_64+0x35/0x87
       entry_SYSCALL_64_after_hwframe+0x6e/0x0
    RIP: 0033:0x7fc328603727
    Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed
    ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00
    f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48
    RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727
    RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d
    RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
    R13: 0000000000000000 R14: 00007ffe8eb3f3c8 R15: 00007ffe8eb3f3bc
       </TASK>
    ---[ end trace f43ce73c3c2b13a2 ]---
    RIP: 0010:free_irq_cpu_rmap+0x23/0x7d
    Code: 0f 1f 80 00 00 00 00 48 85 ff 74 6b 55 48 89 fd 53 66 83 7f 06 00
    74 24 31 db 48 8b 55 08 0f b7 c3 48 8b 04 c2 48 85 c0 74 09 <8b> 38 31
    f6 e8 c4 0a b8 ff 83 c3 01 66 3b 5d 06 72 de b8 ff ff ff
    RSP: 0018:ff384881640eaca0 EFLAGS: 00010282
    RAX: e277a58fde16f291 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: ff2335e2e20b3600 RSI: 0000000000000000 RDI: ff2335e2e20b3400
    RBP: ff2335e2e20b3400 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 00000000ffffffe4 R12: ff384881640ead88
    R13: ff2335c3760751e0 R14: ff2335e2e1672200 R15: ff2335c3760751f8
    FS:  00007fc32ac22480(0000) GS:ff2335e2d6e00000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f651ab54000 CR3: 00000029f1206003 CR4: 0000000000771ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Kernel panic - not syncing: Fatal exception
    Kernel Offset: 0x1dc00000 from 0xffffffff81000000 (relocation range:
    0xffffffff80000000-0xffffffffbfffffff)
    kvm-guest: disable async PF for cpu 0
    
    Fixes: 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation")
    Signed-off-by: Mohith Kumar Thummaluru<[email protected]>
    Tested-by: Mohith Kumar Thummaluru<[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Reviewed-by: Shay Drori <[email protected]>
    Signed-off-by: Pradyumn Rahar <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Zhigulin <[email protected]>
Date:   Thu Nov 13 16:57:44 2025 +0300

    net: dsa: hellcreek: fix missing error handling in LED registration
    
    [ Upstream commit e6751b0b19a6baab219a62e1e302b8aa6b5a55b2 ]
    
    The LED setup routine registered both led_sync_good
    and led_is_gm devices without checking the return
    values of led_classdev_register(). If either registration
    failed, the function continued silently, leaving the
    driver in a partially-initialized state and leaking
    a registered LED classdev.
    
    Add proper error handling
    
    Fixes: 7d9ee2e8ff15 ("net: dsa: hellcreek: Add PTP status LEDs")
    Signed-off-by: Pavel Zhigulin <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Acked-by: Kurt Kanzenbach <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Oleksij Rempel <[email protected]>
Date:   Fri Nov 14 10:09:51 2025 +0100

    net: dsa: microchip: lan937x: Fix RGMII delay tuning
    
    commit 3ceb6ac2116ecda1c5d779bb73271479e70fccb4 upstream.
    
    Correct RGMII delay application logic in lan937x_set_tune_adj().
    
    The function was missing `data16 &= ~PORT_TUNE_ADJ` before setting the
    new delay value. This caused the new value to be bitwise-OR'd with the
    existing PORT_TUNE_ADJ field instead of replacing it.
    
    For example, when setting the RGMII 2 TX delay on port 4, the
    intended TUNE_ADJUST value of 0 (RGMII_2_TX_DELAY_2NS) was
    incorrectly OR'd with the default 0x1B (from register value 0xDA3),
    leaving the delay at the wrong setting.
    
    This patch adds the missing mask to clear the field, ensuring the
    correct delay value is written. Physical measurements on the RGMII TX
    lines confirm the fix, showing the delay changing from ~1ns (before
    change) to ~2ns.
    
    While testing on i.MX 8MP showed this was within the platform's timing
    tolerance, it did not match the intended hardware-characterized value.
    
    Fixes: b19ac41faa3f ("net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config")
    Cc: [email protected]
    Signed-off-by: Oleksij Rempel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Nishanth Menon <[email protected]>
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 <[email protected]>
    Suggested-by: Jacob Keller <[email protected]>
    Signed-off-by: Nishanth Menon <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Zhigulin <[email protected]>
Date:   Thu Nov 13 19:19:21 2025 +0300

    net: mlxsw: linecards: fix missing error check in mlxsw_linecard_devlink_info_get()
    
    [ Upstream commit b0c959fec18f4595a6a6317ffc30615cfa37bf69 ]
    
    The call to devlink_info_version_fixed_put() in
    mlxsw_linecard_devlink_info_get() did not check for errors,
    although it is checked everywhere in the code.
    
    Add missed 'err' check to the mlxsw_linecard_devlink_info_get()
    
    Fixes: 3fc0c51905fb ("mlxsw: core_linecards: Expose device PSID over device info")
    Signed-off-by: Pavel Zhigulin <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ilya Maximets <[email protected]>
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 <[email protected]>
    Signed-off-by: Ilya Maximets <[email protected]>
    Acked-by: Eelco Chaudron <[email protected]>
    Reviewed-by: Aaron Conole <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Pavel Zhigulin <[email protected]>
Date:   Thu Nov 13 14:27:56 2025 +0300

    net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()
    
    [ Upstream commit 896f1a2493b59beb2b5ccdf990503dbb16cb2256 ]
    
    The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate
    over 'cqe->len_list[]' using only a zero-length terminator as
    the stopping condition. If the terminator was missing or
    malformed, the loop could run past the end of the fixed-size array.
    
    Add an explicit bound check using ARRAY_SIZE() in both loops to prevent
    a potential out-of-bounds access.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 55482edc25f0 ("qede: Add slowpath/fastpath support and enable hardware GRO")
    Signed-off-by: Pavel Zhigulin <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shahar Shitrit <[email protected]>
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 <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Shahar Shitrit <[email protected]>
Date:   Sun Oct 26 22:03:01 2025 +0200

    net: tls: Change async resync helpers argument
    
    [ Upstream commit 34892cfec0c2d96787c4be7bda0d5f18d7dacf85 ]
    
    Update tls_offload_rx_resync_async_request_start() and
    tls_offload_rx_resync_async_request_end() to get a struct
    tls_offload_resync_async parameter directly, rather than
    extracting it from struct sock.
    
    This change aligns the function signatures with the upcoming
    tls_offload_rx_resync_async_request_cancel() helper, which
    will be introduced in a subsequent patch.
    
    Signed-off-by: Shahar Shitrit <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Nam Cao <[email protected]>
Date:   Mon Nov 17 08:42:31 2025 +0000

    nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot
    
    commit 949f1fd2225baefbea2995afa807dba5cbdb6bd3 upstream.
    
    nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a
    kmemleak warning.
    
    Make sure this data is deallocated.
    
    Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs")
    Signed-off-by: Nam Cao <[email protected]>
    Cc: [email protected]
    Reviewed-by: Lyude Paul <[email protected]>
    Signed-off-by: Lyude Paul <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Shin'ichiro Kawasaki <[email protected]>
Date:   Mon Nov 17 11:23:39 2025 +0900

    nvme-multipath: fix lockdep WARN due to partition scan work
    
    [ Upstream commit 6d87cd5335784351280f82c47cc8a657271929c3 ]
    
    Blktests test cases nvme/014, 057 and 058 fail occasionally due to a
    lockdep WARN. As reported in the Closes tag URL, the WARN indicates that
    a deadlock can happen due to the dependency among disk->open_mutex,
    kblockd workqueue completion and partition_scan_work completion.
    
    To avoid the lockdep WARN and the potential deadlock, cut the dependency
    by running the partition_scan_work not by kblockd workqueue but by
    nvme_wq.
    
    Reported-by: Yi Zhang <[email protected]>
    Closes: https://lore.kernel.org/linux-block/CAHj4cs8mJ+R_GmQm9R8ebResKAWUE8kF5+_WVg0v8zndmqd6BQ@mail.gmail.com/
    Link: https://lore.kernel.org/linux-block/oeyzci6ffshpukpfqgztsdeke5ost5hzsuz4rrsjfmvpqcevax@5nhnwbkzbrpa/
    Fixes: 1f021341eef4 ("nvme-multipath: defer partition scanning")
    Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Ewan D. Milne <[email protected]>
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: [email protected]
    Tested-by: Marco Patalano <[email protected]>
    Reviewed-by: Justin Tee <[email protected]>
    Signed-off-by: Ewan D. Milne <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Ewan D. Milne <[email protected]>
Date:   Mon Nov 10 16:20:00 2025 -0500

    nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()
    
    commit ea3442efabd0aa3930c5bab73c3901ef38ef6ac3 upstream.
    
    Now target is removed from nvme_fc_ctrl_free() which is the ctrl->ref
    release handler. And even admin queue is unquiesced there, this way
    is definitely wrong because the ctr->ref is grabbed when submitting
    command.
    
    And Marco observed that nvme_fc_ctrl_free() can be called from request
    completion code path, and trigger kernel warning since request completes
    from softirq context.
    
    Fix the issue by moveing target removal into nvme_fc_delete_ctrl(),
    which is also aligned with nvme-tcp and nvme-rdma.
    
    Patch originally proposed by Ming Lei, then modified to move the tagset
    removal down to after nvme_fc_delete_association() after further testing.
    
    Cc: Marco Patalano <[email protected]>
    Cc: Ewan Milne <[email protected]>
    Cc: James Smart <[email protected]>
    Cc: Sagi Grimberg <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Cc: [email protected]
    Tested-by: Marco Patalano <[email protected]>
    Reviewed-by: Justin Tee <[email protected]>
    Signed-off-by: Ewan D. Milne <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Haotian Zhang <[email protected]>
Date:   Tue Oct 28 11:05:09 2025 +0800

    pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()
    
    [ Upstream commit 9b07cdf86a0b90556f5b68a6b20b35833b558df3 ]
    
    The driver calls fwnode_get_named_child_node() which takes a reference
    on the child node, but never releases it, which causes a reference leak.
    
    Fix by using devm_add_action_or_reset() to automatically release the
    reference when the device is removed.
    
    Fixes: d5282a539297 ("pinctrl: cs42l43: Add support for the cs42l43")
    Suggested-by: Charles Keepax <[email protected]>
    Signed-off-by: Haotian Zhang <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Yu-Chun Lin <[email protected]>
Date:   Thu Oct 23 15:55:29 2025 +0800

    pinctrl: realtek: Select REGMAP_MMIO for RTD driver
    
    [ Upstream commit 369f772299821f93f872bf1b4d7d7ed2fc50243b ]
    
    The pinctrl-rtd driver uses 'devm_regmap_init_mmio', which requires
    'REGMAP_MMIO' to be enabled.
    
    Without this selection, the build fails with an undefined reference:
    aarch64-none-linux-gnu-ld: drivers/pinctrl/realtek/pinctrl-rtd.o: in
    function rtd_pinctrl_probe': pinctrl-rtd.c:(.text+0x5a0): undefined
    reference to __devm_regmap_init_mmio_clk'
    
    Fix this by selecting 'REGMAP_MMIO' in the Kconfig.
    
    Fixes: e99ce78030db ("pinctrl: realtek: Add common pinctrl driver for Realtek DHC RTD SoCs")
    Signed-off-by: Yu-Chun Lin <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jared Kangas <[email protected]>
Date:   Tue Nov 11 13:54:11 2025 -0800

    pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc
    
    [ Upstream commit 97ea34defbb57bfaf71ce487b1b0865ffd186e81 ]
    
    s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its
    fields are initialized. Notably, num_custom_params is used in
    pinconf_generic_parse_dt_config(), resulting in intermittent allocation
    errors, such as the following splat when probing i2c-imx:
    
            WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300
            [...]
            Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT)
            [...]
            Call trace:
             __alloc_pages_noprof+0x290/0x300 (P)
             ___kmalloc_large_node+0x84/0x168
             __kmalloc_large_node_noprof+0x34/0x120
             __kmalloc_noprof+0x2ac/0x378
             pinconf_generic_parse_dt_config+0x68/0x1a0
             s32_dt_node_to_map+0x104/0x248
             dt_to_map_one_config+0x154/0x1d8
             pinctrl_dt_to_map+0x12c/0x280
             create_pinctrl+0x6c/0x270
             pinctrl_get+0xc0/0x170
             devm_pinctrl_get+0x50/0xa0
             pinctrl_bind_pins+0x60/0x2a0
             really_probe+0x60/0x3a0
            [...]
             __platform_driver_register+0x2c/0x40
             i2c_adap_imx_init+0x28/0xff8 [i2c_imx]
            [...]
    
    This results in later parse failures that can cause issues in dependent
    drivers:
    
            s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property
            s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property
            [...]
            pca953x 0-0022: failed writing register: -6
            i2c i2c-0: IMX I2C adapter registered
            s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property
            s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property
            i2c i2c-1: IMX I2C adapter registered
            s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property
            s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property
            i2c i2c-2: IMX I2C adapter registered
    
    Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of
    devm_kmalloc() in s32_pinctrl_probe(), which sets the previously
    uninitialized fields to zero.
    
    Fixes: fd84aaa8173d ("pinctrl: add NXP S32 SoC family support")
    Signed-off-by: Jared Kangas <[email protected]>
    Tested-by: Jan Petrous (OSS) <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jared Kangas <[email protected]>
Date:   Tue Nov 11 13:54:12 2025 -0800

    pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()
    
    [ Upstream commit 6010d4d8b55b5d3ae1efb5502c54312e15c14f21 ]
    
    s32_pmx_gpio_request_enable() does not initialize the newly-allocated
    gpio_pin_config::list before adding it to s32_pinctrl::gpio_configs.
    This could result in a linked list corruption.
    
    Initialize the new list_head with INIT_LIST_HEAD() to fix this.
    
    Fixes: fd84aaa8173d ("pinctrl: add NXP S32 SoC family support")
    Signed-off-by: Jared Kangas <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Haotian Zhang <[email protected]>
Date:   Mon Nov 17 11:33:54 2025 +0800

    platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to errnos
    
    [ Upstream commit d8bb447efc5622577994287dc77c684fa8840b30 ]
    
    isst_if_probe() uses pci_read_config_dword() that returns PCIBIOS_*
    codes. The return code is returned from the probe function as is but
    probe functions should return normal errnos. A proper implementation
    can be found in drivers/leds/leds-ss4200.c.
    
    Convert PCIBIOS_* return codes using pcibios_err_to_errno() into
    normal errno before returning.
    
    Fixes: d3a23584294c ("platform/x86: ISST: Add Intel Speed Select mmio interface")
    Signed-off-by: Haotian Zhang <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Armin Wolf <[email protected]>
Date:   Mon Nov 10 12:12:53 2025 +0100

    platform/x86: msi-wmi-platform: Fix typo in WMI GUID
    
    [ Upstream commit 97b726eb1dc2b4a2532544eb3da72bb6acbd39a3 ]
    
    The WMI driver core only supports GUID strings containing only
    uppercase characters, however the GUID string used by the
    msi-wmi-platform driver contains a single lowercase character.
    This prevents the WMI driver core from matching said driver to
    its WMI device.
    
    Fix this by turning the lowercase character into a uppercase
    character. Also update the WMI driver development guide to warn
    about this.
    
    Reported-by: Antheas Kapenekakis <[email protected]>
    Fixes: 9c0beb6b29e7 ("platform/x86: wmi: Add MSI WMI Platform driver")
    Tested-by: Antheas Kapenekakis <[email protected]>
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Armin Wolf <[email protected]>
Date:   Mon Nov 10 12:12:52 2025 +0100

    platform/x86: msi-wmi-platform: Only load on MSI devices
    
    [ Upstream commit c93433fd4e2bbbe7caa67b53d808b4a084852ff3 ]
    
    It turns out that the GUID used by the msi-wmi-platform driver
    (ABBC0F60-8EA1-11D1-00A0-C90629100000) is not unique, but was instead
    copied from the WIndows Driver Samples. This means that this driver
    could load on devices from other manufacturers that also copied this
    GUID, potentially causing hardware errors.
    
    Prevent this by only loading on devices whitelisted via DMI. The DMI
    matches where taken from the msi-ec driver.
    
    Reported-by: Antheas Kapenekakis <[email protected]>
    Fixes: 9c0beb6b29e7 ("platform/x86: wmi: Add MSI WMI Platform driver")
    Tested-by: Antheas Kapenekakis <[email protected]>
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Diogo Ivo <[email protected]>
Date:   Mon Nov 3 14:14:15 2025 +0000

    Revert "drm/tegra: dsi: Clear enable register if powered by bootloader"
    
    commit 660b299bed2a2a55a1f9102d029549d0235f881c upstream.
    
    Commit b6bcbce33596 ("soc/tegra: pmc: Ensure power-domains are in a
    known state") was introduced so that all power domains get initialized
    to a known working state when booting and it does this by shutting them
    down (including asserting resets and disabling clocks) before registering
    each power domain with the genpd framework, leaving it to each driver to
    later on power its needed domains.
    
    This caused the Google Pixel C to hang when booting due to a workaround
    in the DSI driver introduced in commit b22fd0b9639e ("drm/tegra: dsi:
    Clear enable register if powered by bootloader") meant to handle the case
    where the bootloader enabled the DSI hardware module. The workaround relies
    on reading a hardware register to determine the current status and after
    b6bcbce33596 that now happens in a powered down state thus leading to
    the boot hang.
    
    Fix this by reverting b22fd0b9639e since currently we are guaranteed
    that the hardware will be fully reset by the time we start enabling the
    DSI module.
    
    Fixes: b6bcbce33596 ("soc/tegra: pmc: Ensure power-domains are in a known state")
    Cc: [email protected]
    Signed-off-by: Diogo Ivo <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://patch.msgid.link/20251103-diogo-smaug_ec_typec-v1-1-be656ccda391@tecnico.ulisboa.pt
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Charles Keepax <[email protected]>
Date:   Tue Nov 25 10:29:24 2025 +0000

    Revert "gpio: swnode: don't use the swnode's name as the key for GPIO lookup"
    
    This reverts commit 25decf0469d4c91d90aa2e28d996aed276bfc622.
    
    This software node change doesn't actually fix any current issues
    with the kernel, it is an improvement to the lookup process rather
    than fixing a live bug. It also causes a couple of regressions with
    shipping laptops, which relied on the label based lookup.
    
    There is a fix for the regressions in mainline, the first 5 patches
    of [1]. However, those patches are fairly substantial changes and
    given the patch causing the regression doesn't actually fix a bug
    it seems better to just revert it in stable.
    
    CC: [email protected] # 6.12, 6.17
    Link: https://lore.kernel.org/linux-sound/[email protected]/ [1]
    Closes: https://github.com/thesofproject/linux/issues/5599
    Closes: https://github.com/thesofproject/linux/issues/5603
    Acked-by: Bartosz Golaszewski <[email protected]>
    Signed-off-by: Charles Keepax <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Wentao Guan <[email protected]>
Date:   Mon Nov 24 10:14:59 2025 +0800

    Revert "RDMA/irdma: Update Kconfig"
    
    Revert commit 8ced3cb73ccd20e744deab7b49f2b7468c984eb2 which is upstream
    commit 060842fed53f77a73824c9147f51dc6746c1267a
    
    It causes regression in 6.12.58 stable, no issues in upstream.
    
    The Kconfig dependency change 060842fed53f ("RDMA/irdma: Update Kconfig")
    went in linux kernel 6.18 where RDMA IDPF support was merged.
    
    Even though IDPF driver exists in older kernels, it doesn't provide RDMA
    support so there is no need for IRDMA to depend on IDPF in kernels <= 6.17.
    
    Link: https://lore.kernel.org/all/IA1PR11MB7727692DE0ECFE84E9B52F02CBD5A@IA1PR11MB7727.namprd11.prod.outlook.com/
    Link: https://lore.kernel.org/all/IA1PR11MB772718B36A3B27D2F07B0109CBD5A@IA1PR11MB7727.namprd11.prod.outlook.com/
    Cc: [email protected] # v6.12.58
    Signed-off-by: Tatyana Nikolova <[email protected]>
    Signed-off-by: Wentao Guan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Aleksei Nikiforov <[email protected]>
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 <[email protected]>
    Signed-off-by: Aleksei Nikiforov <[email protected]>
    Signed-off-by: Aswin Karuvally <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Heiko Carstens <[email protected]>
Date:   Tue Nov 25 11:46:36 2025 +0100

    s390/mm: Fix __ptep_rdp() inline assembly
    
    [ Upstream commit 31475b88110c4725b4f9a79c3a0d9bbf97e69e1c ]
    
    When a zero ASCE is passed to the __ptep_rdp() inline assembly, the
    generated instruction should have the R3 field of the instruction set to
    zero. However the inline assembly is written incorrectly: for such cases a
    zero is loaded into a register allocated by the compiler and this register
    is then used by the instruction.
    
    This means that selected TLB entries may not be flushed since the specified
    ASCE does not match the one which was used when the selected TLB entries
    were created.
    
    Fix this by removing the asce and opt parameters of __ptep_rdp(), since
    all callers always pass zero, and use a hard-coded register zero for
    the R3 field.
    
    Fixes: 0807b856521f ("s390/mm: add support for RDP (Reset DAT-Protection)")
    Cc: [email protected]
    Reviewed-by: Gerald Schaefer <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bart Van Assche <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/linux-block/pnezafputodmqlpumwfbn644ohjybouveehcjhz2hmhtcf2rka@sdhoiivync4y/
    Cc: Ming Lei <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Signed-off-by: Bart Van Assche <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Tested-by: Sebastian Reichel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Bart Van Assche <[email protected]>
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: [email protected]
    Closes: https://lore.kernel.org/linux-scsi/[email protected]/
    Cc: Hannes Reinecke <[email protected]>
    Cc: [email protected]
    Fixes: 97d27b0dd015 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()")
    Signed-off-by: Bart Van Assche <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Hamza Mahfooz <[email protected]>
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: [email protected]
    Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs")
    Signed-off-by: Hamza Mahfooz <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Reviewed-by: Allen Pais <[email protected]>
    Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linux.microsoft.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Tue Nov 18 08:20:26 2025 +0100

    selftests: mptcp: join: endpoints: longer timeout
    
    commit fb13c6bb810ca871964e062cf91882d1c83db509 upstream.
    
    In rare cases, when the test environment is very slow, some endpoints
    tests can fail because some expected events have not been seen.
    
    Because the tests are expecting a long on-going connection, and they are
    not waiting for the end of the transfer, it is fine to have a longer
    timeout, and even go over the default one. This connection will be
    killed at the end, after the verifications: increasing the timeout
    doesn't change anything, apart from avoiding it to end before the end of
    the verifications.
    
    To play it safe, all endpoints tests not waiting for the end of the
    transfer are now having a longer timeout: 2 minutes.
    
    The Fixes commit was making the connection longer, but still, the
    default timeout would have stopped it after 1 minute, which might not be
    enough in very slow environments.
    
    Fixes: 6457595db987 ("selftests: mptcp: join: endpoints: longer transfer")
    Cc: [email protected]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Reviewed-by: Geliang Tang <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-8-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Tue Nov 18 08:20:27 2025 +0100

    selftests: mptcp: join: userspace: longer timeout
    
    commit 0e4ec14dc1ee4b1ec347729c225c3ca950f2bcf6 upstream.
    
    In rare cases, when the test environment is very slow, some userspace
    tests can fail because some expected events have not been seen.
    
    Because the tests are expecting a long on-going connection, and they are
    not waiting for the end of the transfer, it is fine to have a longer
    timeout, and even go over the default one. This connection will be
    killed at the end, after the verifications: increasing the timeout
    doesn't change anything, apart from avoiding it to end before the end of
    the verifications.
    
    To play it safe, all userspace tests not waiting for the end of the
    transfer are now having a longer timeout: 2 minutes.
    
    The Fixes commit was making the connection longer, but still, the
    default timeout would have stopped it after 1 minute, which might not be
    enough in very slow environments.
    
    Fixes: 290493078b96 ("selftests: mptcp: join: userspace: longer transfer")
    Cc: [email protected]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Reviewed-by: Geliang Tang <[email protected]>
    Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-9-806d3781c95f@kernel.org
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Ido Schimmel <[email protected]>
Date:   Sun Nov 16 10:10:29 2025 +0200

    selftests: net: lib: Do not overwrite error messages
    
    [ Upstream commit bed22c7b90af732978715a1789bca1c3cfa245a6 ]
    
    ret_set_ksft_status() calls ksft_status_merge() with the current return
    status and the last one. It treats a non-zero return code from
    ksft_status_merge() as an indication that the return status was
    overwritten by the last one and therefore overwrites the return message
    with the last one.
    
    Currently, ksft_status_merge() returns a non-zero return code even if
    the current return status and the last one are equal. This results in
    return messages being overwritten which is counter-productive since we
    are more interested in the first failure message and not the last one.
    
    Fix by changing ksft_status_merge() to only return a non-zero return
    code if the current return status was actually changed.
    
    Add a test case which checks that the first error message is not
    overwritten.
    
    Before:
    
     # ./lib_sh_test.sh
     [...]
     TEST: RET tfail2 tfail -> fail                                      [FAIL]
            retmsg=tfail expected tfail2
     [...]
     # echo $?
     1
    
    After:
    
     # ./lib_sh_test.sh
     [...]
     TEST: RET tfail2 tfail -> fail                                      [ OK ]
     [...]
     # echo $?
     0
    
    Fixes: 596c8819cb78 ("selftests: forwarding: Have RET track kselftest framework constants")
    Reviewed-by: Petr Machata <[email protected]>
    Signed-off-by: Ido Schimmel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Po-Hsu Lin <[email protected]>
Date:   Mon Oct 27 17:57:10 2025 +0800

    selftests: net: use BASH for bareudp testing
    
    [ Upstream commit 9311e9540a8b406d9f028aa87fb072a3819d4c82 ]
    
    In bareudp.sh, this script uses /bin/sh and it will load another lib.sh
    BASH script at the very beginning.
    
    But on some operating systems like Ubuntu, /bin/sh is actually pointed to
    DASH, thus it will try to run BASH commands with DASH and consequently
    leads to syntax issues:
      # ./bareudp.sh: 4: ./lib.sh: Bad substitution
      # ./bareudp.sh: 5: ./lib.sh: source: not found
      # ./bareudp.sh: 24: ./lib.sh: Syntax error: "(" unexpected
    
    Fix this by explicitly using BASH for bareudp.sh. This fixes test
    execution failures on systems where /bin/sh is not BASH.
    
    Reported-by: Edoardo Canepa <[email protected]>
    Link: https://bugs.launchpad.net/bugs/2129812
    Signed-off-by: Po-Hsu Lin <[email protected]>
    Reviewed-by: Przemek Kitszel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Mike Yuan <[email protected]>
Date:   Sat Nov 8 19:09:47 2025 +0000

    shmem: fix tmpfs reconfiguration (remount) when noswap is set
    
    commit 3cd1548a278c7d6a9bdef1f1866e7cf66bfd3518 upstream.
    
    In systemd we're trying to switch the internal credentials setup logic
    to new mount API [1], and I noticed fsconfig(FSCONFIG_CMD_RECONFIGURE)
    consistently fails on tmpfs with noswap option. This can be trivially
    reproduced with the following:
    
    ```
    int fs_fd = fsopen("tmpfs", 0);
    fsconfig(fs_fd, FSCONFIG_SET_FLAG, "noswap", NULL, 0);
    fsconfig(fs_fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
    fsmount(fs_fd, 0, 0);
    fsconfig(fs_fd, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0);  <------ EINVAL
    ```
    
    After some digging the culprit is shmem_reconfigure() rejecting
    !(ctx->seen & SHMEM_SEEN_NOSWAP) && sbinfo->noswap, which is bogus
    as ctx->seen serves as a mask for whether certain options are touched
    at all. On top of that, noswap option doesn't use fsparam_flag_no,
    hence it's not really possible to "reenable" swap to begin with.
    Drop the check and redundant SHMEM_SEEN_NOSWAP flag.
    
    [1] https://github.com/systemd/systemd/pull/39637
    
    Fixes: 2c6efe9cf2d7 ("shmem: add support to ignore swap")
    Signed-off-by: Mike Yuan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: Luis Chamberlain <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Cc: Hugh Dickins <[email protected]>
    Cc: [email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Henrique Carvalho <[email protected]>
Date:   Wed Nov 26 10:55:53 2025 -0300

    smb: client: fix incomplete backport in cfids_invalidation_worker()
    
    The previous commit bdb596ceb4b7 ("smb: client: fix potential UAF in
    smb2_close_cached_fid()") was an incomplete backport and missed one
    kref_put() call in cfids_invalidation_worker() that should have been
    converted to close_cached_dir().
    
    Fixes: 065bd6241227 ("smb: client: fix potential UAF in smb2_close_cached_fid()")"
    Signed-off-by: Henrique Carvalho <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Henrique Carvalho <[email protected]>
Date:   Thu Nov 13 15:09:13 2025 -0300

    smb: client: introduce close_cached_dir_locked()
    
    commit a9d1f38df7ecd0e21233447c9cc6fa1799eddaf3 upstream.
    
    Replace close_cached_dir() calls under cfid_list_lock with a new
    close_cached_dir_locked() variant that uses kref_put() instead of
    kref_put_lock() to avoid recursive locking when dropping references.
    
    While the existing code works if the refcount >= 2 invariant holds,
    this area has proven error-prone. Make deadlocks impossible and WARN
    on invariant violations.
    
    Cc: [email protected]
    Reviewed-by: David Howells <[email protected]>
    Signed-off-by: Henrique Carvalho <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Yipeng Zou <[email protected]>
Date:   Sat Nov 22 09:39:42 2025 +0000

    timers: Fix NULL function pointer race in timer_shutdown_sync()
    
    commit 20739af07383e6eb1ec59dcd70b72ebfa9ac362c upstream.
    
    There is a race condition between timer_shutdown_sync() and timer
    expiration that can lead to hitting a WARN_ON in expire_timers().
    
    The issue occurs when timer_shutdown_sync() clears the timer function
    to NULL while the timer is still running on another CPU. The race
    scenario looks like this:
    
    CPU0                                    CPU1
                                            <SOFTIRQ>
                                            lock_timer_base()
                                            expire_timers()
                                            base->running_timer = timer;
                                            unlock_timer_base()
                                            [call_timer_fn enter]
                                            mod_timer()
                                            ...
    timer_shutdown_sync()
    lock_timer_base()
    // For now, will not detach the timer but only clear its function to NULL
    if (base->running_timer != timer)
            ret = detach_if_pending(timer, base, true);
    if (shutdown)
            timer->function = NULL;
    unlock_timer_base()
                                            [call_timer_fn exit]
                                            lock_timer_base()
                                            base->running_timer = NULL;
                                            unlock_timer_base()
                                            ...
                                            // Now timer is pending while its function set to NULL.
                                            // next timer trigger
                                            <SOFTIRQ>
                                            expire_timers()
                                            WARN_ON_ONCE(!fn) // hit
                                            ...
    lock_timer_base()
    // Now timer will detach
    if (base->running_timer != timer)
            ret = detach_if_pending(timer, base, true);
    if (shutdown)
            timer->function = NULL;
    unlock_timer_base()
    
    The problem is that timer_shutdown_sync() clears the timer function
    regardless of whether the timer is currently running. This can leave a
    pending timer with a NULL function pointer, which triggers the
    WARN_ON_ONCE(!fn) check in expire_timers().
    
    Fix this by only clearing the timer function when actually detaching the
    timer. If the timer is running, leave the function pointer intact, which is
    safe because the timer will be properly detached when it finishes running.
    
    Fixes: 0cc04e80458a ("timers: Add shutdown mechanism to the internal functions")
    Signed-off-by: Yipeng Zou <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Chen Pei <[email protected]>
Date:   Fri Nov 14 15:12:15 2025 +0800

    tools: riscv: Fixed misalignment of CSR related definitions
    
    [ Upstream commit e2cb69263e797c0aa6676bcef23e9e27e44c83b0 ]
    
    The file tools/arch/riscv/include/asm/csr.h borrows from
    arch/riscv/include/asm/csr.h, and subsequent modifications
    related to CSR should maintain consistency.
    
    Signed-off-by: Chen Pei <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [[email protected]: dropped Fixes: lines for patches that weren't broken; removed superfluous blank line]
    Signed-off-by: Paul Walmsley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Zhang Chujun <[email protected]>
Date:   Thu Nov 6 11:10:40 2025 +0800

    tracing/tools: Fix incorrcet short option in usage text for --threads
    
    [ Upstream commit 53afec2c8fb2a562222948cb1c2aac48598578c9 ]
    
    The help message incorrectly listed '-t' as the short option for
    --threads, but the actual getopt_long configuration uses '-e'.
    This mismatch can confuse users and lead to incorrect command-line
    usage. This patch updates the usage string to correctly show:
            "-e, --threads NRTHR"
    to match the implementation.
    
    Note: checkpatch.pl reports a false-positive spelling warning on
    'Run', which is intentional.
    
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Zhang Chujun <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jari Ruusu <[email protected]>
Date:   Sat Nov 22 07:28:00 2025 +0000

    tty/vt: fix up incorrect backport to stable releases
    
    Below is a patch for 6.12.58+ and 6.17.8+ stable branches only.
    Upstream does not need this.
    
    Signed-off-by: Jari Ruusu <[email protected]>
    Fixes: da7e8b382396 ("tty/vt: Add missing return value for VT_RESIZE in vt_ioctl()")
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Michal Luczaj <[email protected]>
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/[email protected]/
    [2]: https://lore.kernel.org/netdev/[email protected]/
    [3]: https://lore.kernel.org/netdev/[email protected]/
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Signed-off-by: Michal Luczaj <[email protected]>
    Reviewed-by: Stefano Garzarella <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Borislav Petkov (AMD) <[email protected]>
Date:   Thu Oct 23 14:46:29 2025 +0200

    x86/microcode/AMD: Limit Entrysign signature checking to known generations
    
    [ Upstream commit 8a9fb5129e8e64d24543ebc70de941a2d77a9e77 ]
    
    Limit Entrysign sha256 signature checking to CPUs in the range Zen1-Zen5.
    
    X86_BUG cannot be used here because the loading on the BSP happens way
    too early, before the cpufeatures machinery has been set up.
    
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://patch.msgid.link/all/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jianbo Liu <[email protected]>
Date:   Tue Oct 28 04:22:48 2025 +0200

    xfrm: Determine inner GSO type from packet inner protocol
    
    [ Upstream commit 61fafbee6cfed283c02a320896089f658fa67e56 ]
    
    The GSO segmentation functions for ESP tunnel mode
    (xfrm4_tunnel_gso_segment and xfrm6_tunnel_gso_segment) were
    determining the inner packet's L2 protocol type by checking the static
    x->inner_mode.family field from the xfrm state.
    
    This is unreliable. In tunnel mode, the state's actual inner family
    could be defined by x->inner_mode.family or by
    x->inner_mode_iaf.family. Checking only the former can lead to a
    mismatch with the actual packet being processed, causing GSO to create
    segments with the wrong L2 header type.
    
    This patch fixes the bug by deriving the inner mode directly from the
    packet's inner protocol stored in XFRM_MODE_SKB_CB(skb)->protocol.
    
    Instead of replicating the code, this patch modifies the
    xfrm_ip2inner_mode helper function. It now correctly returns
    &x->inner_mode if the selector family (x->sel.family) is already
    specified, thereby handling both specific and AF_UNSPEC cases
    appropriately.
    
    With this change, ESP GSO can use xfrm_ip2inner_mode to get the
    correct inner mode. It doesn't affect existing callers, as the updated
    logic now mirrors the checks they were already performing externally.
    
    Fixes: 26dbd66eab80 ("esp: choose the correct inner protocol for GSO on inter address family tunnels")
    Signed-off-by: Jianbo Liu <[email protected]>
    Reviewed-by: Cosmin Ratiu <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sabrina Dubroca <[email protected]>
Date:   Thu Oct 16 12:39:12 2025 +0200

    xfrm: drop SA reference in xfrm_state_update if dir doesn't match
    
    [ Upstream commit 8d2a2a49c30f67a480fa9ed25e08436a446f057e ]
    
    We're not updating x1, but we still need to put() it.
    
    Fixes: a4a87fa4e96c ("xfrm: Add Direction to the SA in or out")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Jianbo Liu <[email protected]>
Date:   Wed Oct 29 11:50:25 2025 +0200

    xfrm: Prevent locally generated packets from direct output in tunnel mode
    
    [ Upstream commit 59630e2ccd728703cc826e3a3515d70f8c7a766c ]
    
    Add a check to ensure locally generated packets (skb->sk != NULL) do
    not use direct output in tunnel mode, as these packets require proper
    L2 header setup that is handled by the normal XFRM processing path.
    
    Fixes: 5eddd76ec2fd ("xfrm: fix tunnel mode TX datapath in packet offload mode")
    Signed-off-by: Jianbo Liu <[email protected]>
    Reviewed-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Sabrina Dubroca <[email protected]>
Date:   Thu Oct 16 12:39:16 2025 +0200

    xfrm: set err and extack on failure to create pcpu SA
    
    [ Upstream commit 1dcf617bec5cb85f68ca19969e7537ef6f6931d3 ]
    
    xfrm_state_construct can fail without setting an error if the
    requested pcpu_num value is too big. Set err and add an extack message
    to avoid confusing userspace.
    
    Fixes: 1ddf9916ac09 ("xfrm: Add support for per cpu xfrm state handling.")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Author: Darrick J. Wong <[email protected]>
Date:   Mon Nov 24 12:56:06 2025 -0500

    xfs: fix out of bounds memory read error in symlink repair
    
    [ Upstream commit 678e1cc2f482e0985a0613ab4a5bf89c497e5acc ]
    
    xfs/286 produced this report on my test fleet:
    
     ==================================================================
     BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110
    
     Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184):
      memcpy_orig+0x54/0x110
      xrep_symlink_salvage_inline+0xb3/0xf0 [xfs]
      xrep_symlink_salvage+0x100/0x110 [xfs]
      xrep_symlink+0x2e/0x80 [xfs]
      xrep_attempt+0x61/0x1f0 [xfs]
      xfs_scrub_metadata+0x34f/0x5c0 [xfs]
      xfs_ioc_scrubv_metadata+0x387/0x560 [xfs]
      xfs_file_ioctl+0xe23/0x10e0 [xfs]
      __x64_sys_ioctl+0x76/0xc0
      do_syscall_64+0x4e/0x1e0
      entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
     kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128
    
     allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago):
      xfs_init_local_fork+0x79/0xe0 [xfs]
      xfs_iformat_local+0xa4/0x170 [xfs]
      xfs_iformat_data_fork+0x148/0x180 [xfs]
      xfs_inode_from_disk+0x2cd/0x480 [xfs]
      xfs_iget+0x450/0xd60 [xfs]
      xfs_bulkstat_one_int+0x6b/0x510 [xfs]
      xfs_bulkstat_iwalk+0x1e/0x30 [xfs]
      xfs_iwalk_ag_recs+0xdf/0x150 [xfs]
      xfs_iwalk_run_callbacks+0xb9/0x190 [xfs]
      xfs_iwalk_ag+0x1dc/0x2f0 [xfs]
      xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs]
      xfs_iwalk+0xa4/0xd0 [xfs]
      xfs_bulkstat+0xfa/0x170 [xfs]
      xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs]
      xfs_file_ioctl+0xbf2/0x10e0 [xfs]
      __x64_sys_ioctl+0x76/0xc0
      do_syscall_64+0x4e/0x1e0
      entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
     CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy)  3d744dd94e92690f00a04398d2bd8631dcef1954
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014
     ==================================================================
    
    On further analysis, I realized that the second parameter to min() is
    not correct.  xfs_ifork::if_bytes is the size of the xfs_ifork::if_data
    buffer.  if_bytes can be smaller than the data fork size because:
    
    (a) the forkoff code tries to keep the data area as large as possible
    (b) for symbolic links, if_bytes is the ondisk file size + 1
    (c) forkoff is always a multiple of 8.
    
    Case in point: for a single-byte symlink target, forkoff will be
    8 but the buffer will only be 2 bytes long.
    
    In other words, the logic here is wrong and we walk off the end of the
    incore buffer.  Fix that.
    
    Cc: [email protected] # v6.10
    Fixes: 2651923d8d8db0 ("xfs: online repair of symbolic links")
    Signed-off-by: Darrick J. Wong <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Carlos Maiolino <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Author: Marcelo Moreira <[email protected]>
Date:   Mon Nov 24 12:56:05 2025 -0500

    xfs: Replace strncpy with memcpy
    
    [ Upstream commit 33ddc796ecbd50cd6211aa9e9eddbf4567038b49 ]
    
    The changes modernizes the code by aligning it with current kernel best
    practices. It improves code clarity and consistency, as strncpy is deprecated
    as explained in Documentation/process/deprecated.rst. This change does
    not alter the functionality or introduce any behavioral changes.
    
    Suggested-by: Dave Chinner <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Carlos Maiolino <[email protected]>
    Signed-off-by: Marcelo Moreira <[email protected]>
    Reviewed-by: Darrick J. Wong <[email protected]>
    Signed-off-by: Carlos Maiolino <[email protected]>
    Stable-dep-of: 678e1cc2f482 ("xfs: fix out of bounds memory read error in symlink repair")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>